top - download
⟦063cd04b5⟧ Wang Wps File
Length: 69845 (0x110d5)
Types: Wang Wps File
Notes: CMS/SDS/004
Names: »4558A «
Derivation
└─⟦2e54efd14⟧ Bits:30006189 8" Wang WCS floppy, CR 0430A
└─ ⟦this⟧ »4558A «
WangText
…00……00……00……00……00…0…0a……00……00…0…0b…0
/…0d…&…0f…&…06…%…0f……19……09……19……0e……19…
…19……05……18……08……18……0d……18……01……18… …18……06……18……07……17……08……17……0a……17……0e……17……0f……17……00……17……01……17……02……17…
…17… …17……05……17……06……16……09……16……0a……16……0c……16……0d……16……0e……16……0f……16……00……16……01……16……02……16…
…16……07……15……08……15……0f……15……01……15……02……14……86…1 …02… …02… …02…
…02…CMS/SDS/004
…02…840202…02……02…
TDP PACKAGE DESIGN SPECIFICATION
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 GENERAL ........................................
1
1.1 PURPOSE AND SCOPE ..........................
1
1.2 PROJECT REFERENCES .........................
1
1.2.1 Applicable Documents ...................
1
1.2.2 Reference Documents ....................
2
1.3 TERMS AND ABBREVIATIONS ....................
2
2 SUMMARY OF REQUIREMENTS ........................
3
2.1 PACKAGE DESCRIPTION ........................
3
2.2 PACKAGE FUNCTIONS ..........................
4
2.2.1 Main Functions - Normal Operation ......
4
2.2.2 Functional Responsibilities ............
4
2.2.2.1 Initialization And Termination .....
4
2.2.2.2 Checkpointing And Recovery .........
4
2.2.2.3 Error Detecting And Handling .......
5
2.2.2.4 Data Collection ....................
5
2.2.2.5 Security ...........................
5
2.3 CHARACTERISTICS ............................
5
2.3.1 Timing .................................
5
2.3.2 Throughput .............................
5
2.3.3 Flexibility ............................
5
2.3.4 Accuracy ...............................
6
3 ENVIRONMENTS ...................................
7
3.1 EQUIPMENT ..................................
7
3.2 SOFTWARE ...................................
7
3.2.1 System Software ........................
7
3.2.2 Development Software ...................
7
3.3 TDP INTERFACES (VDU-SIM TO CPS ONLY) .....
8
3.3.1 TDP-Files ..............................
9
3.4 FUNCTIONS MAINTAINED BY OTHER PACKAGES .....
10
4 PACKAGE DESIGN .................................
11
4.1 PACKAGE OVERVIEW ...........................
11
4.1.1 Functional Description .................
13
4.1.2 Software Structure .....................
20
4.1.3 Dataflow And Control Logic .............
30
4.1.3.1 Dataflow, TDP-CAMPS As Blackboxes ..
30
4.1.3.2 TDP-Handler-LTUX Interrelationship .
32
4.1.3.3 Dataflow, TDP Internally. ..........
35
4.1.4 Common Package Data ....................
39
4.1.5 Common Package Procedures ..............
50
4.1.5.1 Procedure ERROR MES. ...............
50
4.1.5.1.1 Functional Description .........
50
4.1.5.1.2 Interface ......................
50
4.1.5.1.3 Data Description ...............
50
4.1.5.1.4 Procedure Design ...............
50
4.1.5.2 Procedure CONV ASCIIHEX TO BIN .....
51
4.1.5.2.1 Functional Description .........
51
4.1.5.2.2 Interface ......................
51
4.1.5.2.3 Data Description ...............
51
4.1.5.2.4 Procedure Design ...............
51
4.1.5.3 Procedure CONV ASCIIDEC TO BIN .....
52
4.1.5.3.1 Functional Description .........
52
4.1.5.3.2 Interface ......................
52
4.1.5.3.3 Data Description ...............
52
4.1.5.3.4 Procedure Description ..........
52
4.1.5.4 Procedure HEX ......................
53
4.1.5.4.1 Functional Description .........
53
4.1.5.4.2 Interface ......................
53
4.1.5.4.3 Data Description ...............
53
4.1.5.4.4 Procedure Description ..........
53
4.1.5.5 Procedure DECHEX ...................
54
4.1.5.5.1 Functional Description .........
54
4.1.5.5.2 Interface ......................
54
4.1.5.5.3 Data Description ...............
54
4.1.5.5.4 Procedure Description ..........
54
4.1.5.6 Procedure Compare Bytes ............
55
4.1.5.6.1 Functional Description .........
55
4.1.5.6.2 Interface ......................
55
4.1.5.6.3 Data Description ...............
55
4.1.5.6.4 Procedure Description ..........
55
4.1.6 Global Data ............................
55
4.1.7 Interfaces .............................
56
4.1.7.1 External Interfaces ................
56
4.1.7.2 Package Inteface ...................
57
4.1.7.3 Subpackage Interfaces ..............
57
4.2.1 Script Command Control Subpackage
Specification ..........................
59
4.2.1.1 Functional Specification .............
59
4.2.1.1.1 Open/Close files ...............
61
4.2.1.1.2 Read Script Commands ...........
61
4.2.1.1.3 Read Data ......................
61
4.2.1.1.4 Store Data ...................
62
4.2.1.1.5 Read from VDU ..................
62
4.2.1.1.5 Write to VDU ...................
62
4.2.1.1.5 Initialization .................
62
4.2.1.1.6 Error Processing ...............
62
4.2.1.1.7 Close Down .....................
62
4.2.1.2 Subpackage Software Structure ......
63
4.2.1.3 Data Flow and Control Logic ........
65
4.2.1.4 Module Specification ...............
66
4.2.1.4.1 Start Up Module ................
66
4.2.1.4.1.1 Functional Specification ...
66
4.2.1.4.1.2 Module Interface Definition
66
4.2.1.4.1.3 Module Components ........
66
4.2.1.4.1.4 Data Description ...........
66
4.2.1.4.1.5 Module Design ..............
67
4.2.1.4.2 Script Command Handling Module .
68
4.2.1.4.2.1 Functional Description .....
68
4.2.1.4.2.2 Module Interface Definition
68
4.2.1.4.2.3 Module-Components ..........
68
4.2.1.4.2.4 Data Description ..........
70
4.2.1.4.2.5 Module Design ..............
70
4.2.1.4.3 VDU Handling Module ............
71
4.2.1.4.3.1 Functional Description ....
71
4.2.1.4.3.2 Module Interface Definition
71
4.2.1.4.3.3 Module Components ..........
71
4.2.1.4.3.4 Data Description ...........
72
4.2.1.4.3.5 Module Design ..............
72
4.2.1.4.4 Close Down Module ..............
73
4.2.1.4.4.1 Functional Specification ...
73
4.2.1.4.4.2 Module Interface definition
73
4.2.1.4.4.3 Module Components ..........
73
4.2.1.4.4.4 Data Description ...........
73
4.2.1.4.4.5 Module Design ..............
74
4.2.1.5 Common Subpackage Data ............
75
4.2.1.6 Common Subpackage Procedures .......
75
4.2.1.7 Subpackage Interfaces ..............
75
4.2.2 Simulation Control .....................
76
4.2.2.1 Functional Specification ...........
76
4.2.2.2 Software Structure .................
81
4.2.2.3 Data Flow and Control Logic .......
82
4.2.2.4 Module Specifications ..............
82
4.2.2.4.1 Initialisation-module ..........
83
4.2.2.4.1.1 Functional Specification ..
83
4.2.2.4.1.2 Module Interface Definition
83
4.2.2.4.1.3 Module Components ..........
83
4.2.2.4.1.4 Data Description ...........
84
4.2.2.4.1.5 Module Design ..............
84
4.2.2.4.2 Flow Control ...................
86
4.2.2.4.2.1 Functional Specification ...
86
4.2.2.4.2.2 Module Interface Definition
86
4.2.2.4.2.3 Module Components ..........
86
4.2.2.4.2.4 Data Description ..........
88
4.2.2.4.2.5 Module Design ..............
89
4.2.2.4.3 Termination Control ...........
90
4.2.2.4.3.1 Functional Specification ...
90
4.2.2.4.3.2 Module Interface Definition
90
4.2.2.4.3.3 Module Components ..........
90
4.2.2.4.3.4 Data Description ...........
91
4.2.2.4.3.5 Module Design ..............
91
4.2.2.5 Common Subpackage Data .............
91
4.2.2.6 Common Subpackage Procedures ......
91
4.2.2.7 Subpackage Interfaces .............
92
4.3.2 VDU Split Control ......................
93
4.2.3.1 Functional Description .............
93
4.2.3.2 Software Structure .................
94
4.2.3.3 Dataflow and Control Logic .........
98
4.2.3.4 Module Specification ...............
98
4.2.3.4.1 VDU Split Control Main Module ..
98
4.2.3.4.1.1 Functional Specification ...
98
4.2.3.4.1.2 Module Interface Definition
99
4.2.3.4.1.3 Module Components ..........
99
4.2.3.4.1.4 Data Description ...........
101
4.2.3.4.1.5 Module Design ..............
101
4.2.3.5 Common Subpackage Data .............
102
4.2.3.6 Common Subpackage Procedures .......
102
4.2.4 VDU Handler I/F Subpackage Specification
103
4.2.4.1 Functional Specification ...........
103
4.2.4.1.1 LDU Transfer ...................
105
4.2.4.1.2 LDU Unpacking ..................
105
4.2.4.1.3 Initialization .................
105
4.2.4.1.4 Error Processing ...............
105
4.2.4.2 Subpackage Software Structure ......
105
4.2.4.3 Data Flow and Control Logic ........
107
4.2.4.4 Module Specification ...............
107
4.2.4.4.1 Input Data Module ..............
107
4.2.4.4.1.1 Functional Specification ...
107
4.2.4.4.1.2 Module Interface Definition
107
4.2.4.4.1.3 Module Components ..........
108
4.2.4.4.1.4 Data Description ...........
109
4.2.4.4.1.5 Module Design ..............
109
4.2.4.4.2 Output Data Module .............
111
4.2.4.4.2.1 Functional Specification ...
111
4.2.4.4.2.2 Module Interface Definition
111
4.2.4.4.2.3 Module Components ..........
111
4.2.4.4.2.4 Data Description ...........
112
4.2.4.4.2.5 Module Design ..............
112
4.2.4.5 Data Description ...................
112
4.2.4.6 Common Subpackage Procedure ........
112
4.2.4.7 Subpackage Interfaces ..............
112
4.2.5 Log Subpackage .........................
114
4.2.5.1 Functional Specification ...........
114
4.2.5.2 Software Structure .................
114
4.2.5.3 Data Flow and Control Logic ........
114
4.2.5.4 Module Specification ...............
115
4.2.5.4.1 Functional Specification .......
115
4.2.5.4.2 Interface Definition ...........
115
4.2.5.4.3 Module Components ..............
115
4.2.5.4.4 Data Description ...............
115
5.2.5.4.5 Module Design ..................
116
4.2.5.5 Common Subpackage ..................
116
4.2.5.6 Common Subpackage Procedures .......
116
4.2.5.7 Subpackage Interfaces ..............
116
4.2.6 Interpret Controls .....................
117
4.2.6.1 Functional Specification ...........
117
4.2.6.2 Software Structure .................
117
4.2.6.3 Dataflow and Control Logic .........
118
4.2.6.4 Module Specification ...............
118
4.2.6.4.1 Functional Specification .......
118
4.2.6.4.2 Interface Definition ...........
118
4.2.6.4.3 Module Components ..............
118
4.2.6.4.4 Data Description ...............
118
4.2.6.4.5 Module Design ..................
119
4.2.6.5 Common Subpackage Data .............
119
4.2.6.6 Common Subpackage Procedures .......
119
4.2.7 Common Waiting .........................
120
4.2.7.1 Functional Specification ...........
120
4.2.7.2 Software Structure .................
122
4.2.7.3 Data Flow and Control Logic ........
122
4.2.7.4 Module Specification ...............
122
4.2.7.5 xxxxxxx ............................
122
4.2.7.6 xxxxxxx ............................
122
4.2.7.7 xxxxxxx ............................
122
4.2.8 Offline Command /Datafile Generator
Subpackage Specification ...............
123
4.2.8.1 Functional Specification ...........
123
4.2.8.1.1 Open Files .....................
125
4.2.8.1.2 Read From Input File ...........
125
4.2.8.1.3 Validation .....................
125
4.2.8.1.4 File Generation ................
125
4.2.8.1.5 Initialization .................
125
4.2.8.1.6 Error Processing ...............
126
4.2.8.1.7 Close Down .....................
126
4.2.8.2 Subpackage Software Structure ......
126
4.2.8.3 Data Flow And Control Logic ........
128
4.2.8.4 Module Specification ...............
128
4.2.8.4.1 Command Reading Module .........
128
4.2.8.4.1.1 Functional Specification ...
128
4.2.8.4.1.2 Module Interface Definition
128
4.2.8.4.1.3 Module Components ..........
128
4.2.8.4.1.4 Data Description ...........
129
4.2.8.4.1.5 Module Design ..............
129
4.2.8.4.2 Parameter Reading Module .......
130
4.2.8.4.2.1 Functional Specification ...
130
4.2.8.4.2.2 Module Interface Definition
130
4.2.8.4.2.3 Module Components ..........
131
4.2.8.4.2.4 Data Description ...........
132
4.2.8.4.2.5 Module Design ..............
132
4.2.8.6 Common Subpackage Procedures .......
136
4.2.8.7 Subpackage Interfaces ..............
136
4.3 MEMORY LAYOUT ..............................
145
1 GENERAL
1.1 P̲U̲R̲P̲O̲S̲E̲ ̲A̲N̲D̲ ̲S̲C̲O̲P̲E̲
The purpose of this document is to collect all necessary
information about the Test Drive Package (TDP), in
one place, information necessary to
- understand the overall architecture of TDP
- understand the connection between TDP and TDS/CAMPS
- be able to program the modules in TDP
- maintain the package in the future, that is to
be able to make changes to certain parts, to optimize
the package, to add facilities etc.
The document describes TDP down to a level where programming
and testing all parts of TDP is possible.
1.2 P̲R̲O̲J̲E̲C̲T̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
1.2.1 A̲p̲p̲l̲i̲c̲a̲b̲l̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
CAMPS System Requirements - CPS/210/SYS/001
CAMPS User Procedures and Associated Formats - CPS/230/ICD/0001
CAMPS Input Output Control - CPS/SCD/028
Delta Reference Manual
CAMPS Test Drive System Outline - CPS/TCN/016
TDS System Design + Note (LN/FAH)
Test Drive System (CR)
TP-Design (MP)
LTUX-FW-TDP Design (EJK)
1.2.2 R̲e̲f̲e̲r̲e̲n̲c̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
CR80 Handbook 82/83.
DAMOS PSP's (IOS/TMS/TOS/RTC/PCF/etc.)
CR80 LTU I/F - CSS-MIC/040/NFC/0001.
1.3 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
All defined in CPS/210/SYS/001
2̲ ̲ ̲S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
2.1 P̲a̲c̲k̲a̲g̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
TDP simulates a VDU/w. operator to CAMPS.
The logical interfaces to CAMPS are shown below. Refer
to figure 3.3.1.1 for the physical interfaces.
TDP
FH SSC
CAMPS CAMPS
VUP
Implemented are the main areas:
- message preparation
- comment preparation
- message release
- message/comment receive and delete
2.2 P̲A̲C̲K̲A̲G̲E̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
2.2.1 M̲a̲i̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲-̲ ̲N̲o̲r̲m̲a̲l̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
Main functions performed by TDP in order to simulate
VDU-operation (man/machine interface) are,
- reading of script commands
- taking action according to the command read, that
is f.ex. to:
- put data in split
- send a function key
- delay process
- receive and act on CAMPS VDU commands according
to the "Delta Reference Manual". That includes
sending data to CAMPS.
- time tag and log traffic.
2.2.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲R̲e̲s̲p̲o̲n̲s̲i̲b̲i̲l̲i̲t̲i̲e̲s̲
2.2.2.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲T̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲
Initialization are done in three levels, under TOS
control. STI/TIA are connected in level 1, LTUX'es
are connected in level 2 and VDU's are connected and
opened in level 3, where the simulation will run.
Termination is done automatically by command or by
fault.
2.2.2.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲ ̲A̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
TDP supports no checkpointing. Recovery is tried only
in situations where CAMPS sends an unexpected response
(verify situations).
2.2.2.3 E̲r̲r̲o̲r̲ ̲D̲e̲t̲e̲c̲t̲i̲n̲g̲ ̲A̲n̲d̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
When detecting an error in LDU contents from CAMPS,
LDU lengths or all kinds of LTUX device faults, TDP
displays an error description on the operator VDU and
terminates this error prone VDU process.
2.2.2.4 D̲a̲t̲a̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
All traffic between CAMPS and TDP is time tagged and
logged in LDU format (hex format exactly as sent or
received).
2.2.2.5 S̲e̲c̲u̲r̲i̲t̲y̲
No considerations.
2.3 C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
2.3.1 T̲i̲m̲i̲n̲g̲
Refer to TDS System Design (CR).
2.3.2 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
Refer to TDS System Design (CR).
2.3.3 F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲
TDP is able to handle a wide variety of improvements
in CAMPS as long as the CAMPS repertoire of VDU instructions
is unaltered.
The use of keyboard filters/enable keyboard cannot
be changed in CAMPS without a risk of deadlocking the
TDP process.
It should be pretty easy to add new command features
to TDP involving the offline generator, the input module
(script command module) and the simulator control module.
New VDU instructions should be invoked in the VDU split
module only.
Identification of modules in TDP: Refer to chapter
4.
2.3.4 A̲c̲c̲u̲r̲a̲c̲y̲
TDP's operatability depends very much on the correctness
and the use of script commands and data positioning
(split, line and cursor position should be correct).
User responsibility.
TDP is very sensitive to changes in use of keyboard
filters and enable keybord as described in 2.3.3.
3̲ ̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲S̲
3.1 E̲Q̲U̲I̲P̲M̲E̲N̲T̲
TDP will run on a CR80M with specifications as stated
in TDS System Design (CR), (Ref. 7).
3.2 S̲O̲F̲T̲W̲A̲R̲E̲
3.2.1 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
DAMOS, TOS, IOS, TMS, IOC-TP.
3.2.2 D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
DAMOS/TOS, EDIT, TCI, SWELL, SWELL-DEBUGGER, DAMOS/AMOS-utilities.
3.3 T̲D̲P̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲ ̲(̲V̲D̲U̲-̲S̲I̲M̲ ̲T̲O̲ ̲C̲P̲S̲ ̲O̲N̲L̲Y̲)̲
3.3.1 T̲D̲P̲-̲F̲i̲l̲e̲s̲
3.4 F̲U̲N̲C̲T̲I̲O̲N̲S̲ ̲M̲A̲I̲N̲T̲A̲I̲N̲E̲D̲ ̲B̲Y̲ ̲O̲T̲H̲E̲R̲ ̲P̲A̲C̲K̲A̲G̲E̲S̲
TDP interfaces to a T̲ransparent VDU Handler P̲rotocol
(via IOS/TMS) and through this to a special Transparent
LTUX-FW-Program.
Above protocol and FW are not described in this document.
4̲ ̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲I̲G̲N̲
4.1 P̲A̲C̲K̲A̲G̲E̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
Logically TDP is divided in 2 major parts:
- reading and interpretation of script commands
- control of CAMPS interface (VDU handler interface)
- logging of traffic.
To handle these three logically divided parts, TDP
is further divided in 5 main subpackages, see figure
4.1-1.
TDP reads a command from script file (initiated by
SIM ̲CONTROL, read by SCRIPT ̲COMMAND ̲CONTROL), interprets
the command (SIM ̲CONTROL) and decides how to execute
the command.
Data transmitted to CAMPS are packed in IOC-records
and LDU's before transmitting (VDU ̲SPLIT and VDU ̲HDL
̲IF). Data/commands received from CAMPS are equally
unpacked (from LDU's and IOC records).
All incoming and outgoing traffic (from/to CAMPS) are
time tagged and logged in LDU format (no conversion).
FIGURE 4.1-1
4.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Main functions for each subpackage, shown in figure
4.1-1 are described in the following.
FIGURE 4.1-1a
VDU Simulation Control.
FIGURE 4.1-1b
Command Control.
FIGURE 4.1-1c
VDU Handler Interface
FIGURE 4.1-1d
VDU Split Control.
FIGURE 4.1-1e
Logging
FIGURE 4.1-1f
OFFLINE Script Generation.
4.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
TDP is physically divided in 4 programs running as
processes under TOS,
- offline script generation which is a pure offline
validation and generation of script command and
datafiles
- VDU simulation where the initialization is divided
into three processes,
- assign of STI/TIA
- "assign" of LTUX
- "assign" of VDU, and the VDU simulating parts
in order to be able to simulate several VDU's under
the same LTUX-TIA-STI.
In VDU simulation one "assign STI/TIA" process is executed,
a number of "assign LTUX" processes are executed, and
for each "LTUX" a number of VDU simulations are executed.
See figure 4.1.2-1 overleaf.
FIGURE 4.1.2-1
VDU Simulation in Three Levels.
The internal software structure is shown in figures
4.1.2-2a - 4.1.2-2f overleaf.
Description of the three levels in VDU-simulation is
part of the initialization since they logically belongs
to "bringing the system up".
Coroutine division is shown in figure 4.1.2-3.
FIGURE 4.1.2-2a
FIGURE 4.1.2-2b
Module Structure OFFLINE SCRIPT GENERATION.
FIGURE 4.1.2-2c
Submodule Structure.
FIGURE 4.1.2-2d
FIGURE 4.1.2-2e
FIGURE 4.1.2-2f
FIGURE 4.1.2-3
Coroutines in TDP
4.1.3 D̲a̲t̲a̲f̲l̲o̲w̲ ̲A̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
To clarify the data flow, a situation (prepare new
message) is shown in three levels,
- TDP-CAMPS as blackboxes
- TDP-handler-LTUX interrelationship
- TDP internally.
The situation is described, starting at USER ̲MENU point.
4.1.3.1 D̲a̲t̲a̲f̲l̲o̲w̲,̲ ̲T̲D̲P̲-̲C̲A̲M̲P̲S̲ ̲A̲s̲ ̲B̲l̲a̲c̲k̲b̲o̲x̲e̲s̲
Refer to figure 4.1.3-1.
1. TDP sends function key "COMMAND".
2. CAMPS responds with positioning of cursor in command
line.
3. TDP sends function key "ENTER".
4. CAMPS sends an arm-command requesting data from
command line.
5. TDP sends data ("PRNM")
6. CAMPS sends format A1.
7. TDP answers with sending function key "ENTER" whereafter
8. CAMPS requests data to format A1 via arm-commands.
9. TDP returns data to format A-1 and receives next
formats (A2 and A3) repeating steps 6 to 9
10. until prepare-new-message is finished in format
A3 and CAMPS returns the USER MENU.
FIGURE 4.1.3.1-1
4.1.3.2 T̲D̲P̲-̲H̲a̲n̲d̲l̲e̲r̲-̲L̲T̲U̲X̲ ̲I̲n̲t̲e̲r̲r̲e̲l̲a̲t̲i̲o̲n̲s̲h̲i̲p̲
Only point 1 and 2 described in 4.1.3.1 are described
here since these fully describe the I/O handling.
1. TDP calls IOS procedure APPENDBYTES, sending an
input request to TP ̲LTUX.
2. The input request is routed via TMS, TP (transparent
VDU handler special TDS) and TDX-bus to LTUX-S.
3. TDP calls IOS procedure INITREADBYTES, initiating
an input operation, handing an input buffer to
IOS.
4. IOS initiates an input operation via TMS-TP.
5. TDP calls IOS procedure APPENDBYTES sending a data
buffer (control type KEY) containing a "COMMAND
key".
6. TDP initiates a wait to IOS/TMS (WAITOPERATION)
and waits on reaction from LTUX/CAMPS.
7. IOS-TMS-TP route output to LTUX-S.
8. LTUX-S sends buffer to CAMPS via V24 line.
9. Assuming an errorfree transmission, LTUX-S sends
a transmission status OK back to TDP.
10. IOS/TMS hands transmission status OK to TDP via
the buffer received in 3 above and "releases" thereby
the waiting initiated in point 6.
11. TDP accepts the transmission status OK and initiates
a new INITREADBYTES, handing a new input buffer
to IOS/TMS.
12. IOS/TMS requests input via TP.
13. TDP invokes a new IOS call WAITOPERATION, waiting
for an answer to the input-request appended in
point 1 above, which would be a CAMPS response
upon the "COMMAND ̲KEY".
14. When LTUX-S receives a "cursor positioning" from
CAMPS, it rebases the input-request waiting and
sends the buffer (with cursor positioning) via
TDX-bus to TP ̲TMS ̲IOS.
15. IOS hands over buffer to TDP in the reserved input-buffer
(11. above) and releases thereby the wait (13.).
TDP then internally interprets and acts upon the
"cursor positioning".
TDP tries constantly to keep one input request
in the LTUX and to have one input operation initiated
to immediately receive buffers from LTUX-S.
FIGURE 4.1.3.2-1
4.1.3.3 D̲a̲t̲a̲f̲l̲o̲w̲,̲ ̲T̲D̲P̲ ̲I̲n̲t̲e̲r̲n̲a̲l̲l̲y̲.̲
Below the internal (TDP) routing is shown for a PRNM
as described in 4.1.3.1. Refer to figure 4.1.3.3-1.
1. SIM ̲CONTROL calls SCRIPT ̲CONTROL, initiating reading
of next script command.
2. SCRIPT ̲CONTROL reads a script command (COMMAND:
PRNM) from command file and
3. returns a buffer containing the command to SIM
̲CONTROL.
4. Interpreting the "COMMAND:PRNM", SIM ̲CONTROL generates
the format for a COMMAND ̲KEY, and hands it in a
buffer to VDUH ̲IF.
5. The OUTPUT ̲DATA part of VDUH ̲IF calls LOG for logging
the output buffer.
6. LOG reads the actual time-of-day, copies the output
buffer into a log record buffer together with the
time tag and writes the log record in LOG ̲FILE.
7. OUTPUT ̲DATA then sends the output buffer to CAMPS
(via IOS/TMS-TP-LTUX etc., refer to 4.1.3.2).
8. After a while, INPUT ̲DATA part of VDUH ̲IF receives
one or several buffers from CAMPS containing a
positioning of the cursor in command line and enabling-of-keyboard.
9. VDUH ̲IF transfers immediately received buffer to
LOG ̲HANDLING.
10. LOG ̲HANDLING copies buffer to log record, timetags
it and writes to LOG ̲FILE.
11. VDUH ̲IF unpacks buffer(s) received from CAMPS in
IOC records and calls VDU ̲SPLIT for interpretation
of - and action upon - record contents.
12. Receiving an enable-keyboard, VDU ̲SPLIT signals,
via semaphore, to SIM ̲CONTROL.
13. When VDU ̲SPLIT/VDUH ̲IF have completed interpretation
of buffers, control is handed to SIM ̲CONTROL (by
coroutine-monitor). SIM ̲CONTROL checks the cursor
position and puts data - "PRNM" into command line
of split memory.
14. SIM ̲CONTROL hands a buffer, containing an "ENTER
̲KEY" to OUTPUT ̲DATA, for transmission.
15. OUTPUT ̲DATA sends buffer to LOG ̲HANDLING.
16. LOG ̲HANDLING copies buffer, timetags it, and writes
a log record.
17. OUTPUT ̲DATA sends buffer to CAMPS.
18. Responding to the "ENTER ̲KEY", CAMPS sends an arm-command
requesting data ("PRNM").
19. INPUT ̲DATA (in VDUH ̲IF) receives arm-command and
calls LOG.
20. Buffer is logged with timetag.
21. Arm-command transferred to VDU ̲SPLIT for action.
22. VDU-split fetches data ("PRNM") in split-memory,
packs in IOC record and LDU format, and sends to
OUTPUT ̲DATA for transmission.
23. OUTPUT ̲DATA transfers buffer to LOG, where
24. the buffer is timetagged and logged.
25. OUTPUT ̲DATA sends data buffer to CAMPS, who
26. responds with a number of buffers containing disable
keyboard, format A(x) and enable keyboard.
27. INPUT ̲DATA transfers each buffer received to LOG,
where
28. the buffers are timetagged and logged.
29. Each buffer is unpacked to IOC-records and transferred
to VDU ̲SPLIT for interpretation.
30. In VDU ̲SPLIT all data/formats are transferred to
split-memory, field definitions are updated etc.
31. When VDU ̲SPLIT finally detects an enable keyboard,
it signals to SIM ̲CONTROL.
32. SIM ̲CONTROL calls SCRIPT ̲CONTROL for reading of
data to format A(x).
33. SCRIPT ̲CONTROL reads data records from data file
and
34. updates directly split memory.
35. When last data record to the format has been read,
SCRIPT ̲CONTROL reads a FUNCTION ̲KEY: ENTER in command
file.
36. The function key is handed to SIM ̲CONTROL where
it is packed in IOC record and LDU format before
37. handing to OUTPUT ̲DATA for transmission to CAMPS.
38. OUTPUT ̲DATA calls LOG, where
39. the "ENTER ̲KEY" buffer is timetagged and logged.
40. OUTPUT ̲DATA then sends the "ENTER ̲KEY" buffer to
CAMPS.
41. CAMPS responds by sending a disable keyboard and
a number of arm-commands requesting data to the
format.
42. For each buffer (arm-command) INPUT ̲DATA calls
LOG.
43. LOG timetags and logs received buffer.
44. VDU ̲SPLIT receives and interprets arm-command.
Proper data are packed in IOC and LDU format.
45. The data buffer is transferred to OUTPUT ̲DATA for
transmission.
46. OUTPUT ̲DATA calls LOG
47. where the buffer is timetagged and logged.
48. OUTPUT ̲DATA sends buffers to CAMPS.
A. When last format field has been transmitted, as
described above in 42-48, CAMPS returns next format
and enables keyboard. Flow as 26-48 for each format
in "Prepare-new-message".
B. After receiving last field to the "Prepare-new-message"
CAMPS returns the USER ̲MENU to TDP.
FIGURE 4.1.3.3-1
4.1.4 C̲o̲m̲m̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
Organization of Split Memory:
Split 0
(System)
Split 1
(Commands)
Split 2
Format
Split
TYPE FIELD ̲DEF = RECORD
LINK : INTEGER;
COL : INTEGER;
LENGTH: INTEGER
ATTRIBUTES: INTEGER:
END;
LINE ̲DEF = ARRAY (1..80) OF CHAR;
SPLIT ̲LINE = RECORD
LINE : LINE ̲DEF;
FREF : INTEGER; "pointer to first
field def. in line
END;
"̲S̲p̲l̲i̲t̲ ̲m̲e̲m̲o̲r̲y̲ ̲d̲e̲f̲'̲s̲ ̲c̲o̲n̲t̲i̲n̲u̲e̲d̲
VAR FIELD: ARRAY (1..290) OF FIELD ̲DEF;
EMPTY ̲FIELD: INTEGER; "pointer to list of empty
field-definitions (internally
linked).
NO ̲OF ̲FIELD: INTEGER; "no of used field definitions
SPLIT ̲MEMORY: ARRAY (1..290) OF SPLIT-LINE;
NO ̲OF ̲FIELDS: INTEGER; "no of used field definitions
SPLIT ̲MEMORY: ARRAY (1..290) OF SPLIT ̲LINE;
VDU ̲SPLIT ̲NO,
HOST ̲SPLIT ̲NO: INTEGER; "Split in use.
SPLIT ̲ADDR, "address of split relative
"to split-memory
HOST ̲LINE ̲NO,
VDU ̲LINE ̲NO,
HOST ̲COLUMN ̲NO,
VDU ̲COLUMN ̲NO,
FIRST ̲LINE ̲DISP,
SPLIT ̲MAX ̲LINES,
SPLIT ̲DISP ̲SIZES,
HIGH ̲LINE, "Highest used line in split
FORMAT ̲MODE : ARRAY (0..15) OF INTEGER;
"FORMAT ̲ON/OFF
"index to above are VDU ̲SPLIT ̲NO and/or
HOST ̲SPLIT ̲NO.
Error ̲msg is a common error routine with an action
flag as call parameter showing how serious the error
is:
FATAL ̲ERROR = 1, "write message and abort program
MSG ̲ERROR = 2, "write message and skip rest of
IOC ̲REC
SKIP ̲ERROR = 3, "skip rest of IOC record function
MSG ̲NOACT = 4, "write message.
MSG ̲COUNT,
MSG ̲POINTER,
MESSAGE : INTEGER; "used when calling WRITE ̲VDU
"for outputting messages.
CMD ̲VDU : (WRITE,READ); "used when calling
VDU ̲HANDLING.
"̲S̲e̲m̲a̲p̲h̲o̲r̲e̲s̲
TIME ̲SIGNAL, "used in delay situations
by SIM ̲CONTR.
CAMPS ̲OPERATION, "Waiting point in VDUH
̲IF.
FK ̲SENT, "Function log to CAMPS
HANGING ̲IO, "Waiting point in Common-waiting-routine.
WAIT ̲VDU, "Wait for operator reply
in SCRIPT ̲COMM.
INITIAL ̲SEM, "Initial Synchronization
SEND ̲TO ̲CAMPS: SEMAPHORE; "wait for sending data
to CAMPS.
"̲W̲o̲r̲k̲ ̲A̲r̲e̲a̲ ̲T̲y̲p̲e̲s̲ ̲U̲s̲e̲d̲ ̲G̲l̲o̲b̲a̲l̲l̲y̲
TYPE ARRAY ̲TYPE = ARRAY (1..128) OF CHAR;
MAXI ̲ARRAY = ARRAY (1..500)OF CHAR;
INT ̲ARRAY = ARRAY (1..1) OF INTEGER;
"̲F̲l̲a̲g̲s̲,̲ ̲P̲o̲i̲n̲t̲e̲r̲s̲ ̲E̲t̲c̲.̲
TYPE ERROR ̲OK = (ERROR, OKAY);
VAR COMPL ̲CODE : (OK, NOT ̲OK);
KEYBD ̲LOCK : INTEGER; "TRUE if keyboard is locked.
PFK ̲ENABLED : INTEGER; "1 bit for each programmed
function key (0=enabled)
DATA ̲ENABLED: INTEGER; "0=datakeys (alfa keys)
enabled, 1=disabled.
SYSTEM ̲ENABLED: INTEGER; "System key, 0=enabled
1=disabled.
ENTER ̲ENABLED : INTEGER; ENTER ̲key, 0=enabled,
1=disabled.
LTUX ̲NO : INTEGER; "HEX LTUX ̲VDU ̲identification,
used for error reporting.
LDU ̲SEQ ̲NO : INTEGER; Sequence No. of last received
LDU.
LDU ̲OUTPUT ̲SEQ ̲NO;INTEGER; "Sequence of last sent
LDU.
INS ̲FLAG : BOOLEANS; "Set in SCR ̲DATA if insert
line operation is ongoing.
"̲F̲u̲n̲c̲t̲i̲o̲n̲ ̲K̲e̲y̲ ̲T̲y̲p̲e̲s̲
FUNCTION ̲KEY ̲TYPE =
(SYSTEM, COMMAND, ENTER ̲KEY, CANCEL ̲KEY, DEL ̲AND ̲
PRESENT, RETURN ̲TO ̲CUR ̲MENU, INS ̲LINE);
"̲C̲A̲M̲P̲S̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲T̲y̲p̲e̲s̲
(SION, SIOF, RECV, RESP, RELS, PRNM, PRNC, DIRS)
"̲S̲c̲r̲i̲p̲t̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲T̲y̲p̲e̲s̲
COMMAND ̲TYPE =
(CFK, CVERIFY, CTIME, CDELAY, DDELAYFACTOR, CLABEL,
CEND, CMESSAGE, CREPEAT, CPASSWORD, CSTOP, CTERMINATE,
CQUEUES, CCOMMAND, CDATA).
"̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲V̲a̲r̲i̲a̲b̲l̲e̲s̲ ̲-̲ ̲S̲C̲R̲ ̲C̲O̲N̲T̲R̲O̲L̲/̲S̲I̲M̲ ̲C̲O̲N̲T̲R̲O̲L̲
CMD ̲DELIVER ̲REC:
RECORD
CMD : INTEGER
DATA: ARRAY (1..80) OF CHAR;
END;
Redefinitions of CMD ̲DELIVER ̲REC
TYPE
FK ̲REC = RECORD
CMD: INTEGER;"CFK
FKEY: ARRAY (1..26) OF CHAR;"FK
̲ident.
END,
VERIFY ̲REC= RECORD
CMD: INTEGER;"CVERIFY
NO ̲OF ̲VERIFY:INTEGER;"No of verifications
VERIFICATION:ARRAY (1..NO ̲OF ̲VERIFY)
OF RECORD:
SPLIT ̲NO: INTEGER;
LINE ̲NO: INTEGER;
CURS ̲NO: INTEGER;
LENGTH : INTEGER;"length of
expt ̲cont.
EXPT ̲CONT: ARRAY (1..LENGTH)
OF CHAR
END;
END;
TIME ̲REC= RECORD
CMD: INTEGER; CTIME
HOUR: INTEGER;
MINUTE: INTEGER;
SECONDS:INTEGER;
END
DELAY ̲REC= RECORD
CMD: INTEGER; "CDELAY
SECONDS:INTEGER;
END;
FACTOR ̲REC= RECORD
CMD: INTEGER; "CDELAYFACTOR
FACTOR: INTEGER;
END
QUEUE ̲REC= RECORD
CMD: INTEGER; "CQUEUES
QUEUE TYPE:ARRAY (1..4)OF
CHAR;"RESP/RELS
ACTION: INTEGER; "E;O
END;
VDU ̲REPLY: (TERMINATE, CONTINUE); "Reply from
operator
V̲a̲r̲i̲a̲b̲l̲e̲s̲ ̲U̲s̲e̲d̲ ̲I̲n̲ ̲-̲ ̲S̲I̲M̲ ̲C̲O̲N̲T̲R̲O̲L̲/̲V̲D̲U̲ ̲S̲P̲L̲I̲T̲
VAR
IOC ̲TYPE ̲OF ̲REC: (N ̲DATA, N ̲LINE, N ̲SP1, N ̲SP2,
N ̲CONT).
BUF ̲LENGTH,
BUF ̲INDEX : INTEGER
IT ̲LDU : ARRAY (1..5) OF CHAR;
"interruptype record to send to
"CAMPS - sending of function keys
NOT ̲FOUND : BOOLEAN;
V̲a̲r̲i̲a̲b̲l̲e̲s̲ ̲U̲s̲e̲d̲ ̲I̲n̲ ̲V̲D̲U̲H̲-̲I̲F̲/̲V̲D̲U̲-̲S̲P̲L̲I̲T̲ ̲(̲/̲S̲I̲M̲-̲C̲O̲N̲T̲R̲O̲L̲)̲
TYPE
LDU ̲RECORD ̲TYPES = (PART ̲OF ̲LDU,
START ̲OF ̲LDU,
END ̲OF ̲LDU,
DATA ̲ENTIRE,
CONTR ̲PART,
CONTR ̲START,
CONTR ̲END,
CONTROL ̲ENTIRE);
CONTROL ̲COMMAND ̲TYPES =
(INPUT ̲REQUEST,
CANCEL ̲INP ̲REQ,
CANCEL ̲OUTPUT,
REPORT ̲STATUS ̲REQUEST,
OPEN ̲CHANNEL,
CLOSE ̲CHANNEL);"TDP to
LTUX
STATUS ̲TYPES = (TRANSMISS ̲STATUS,
RECEPTION ̲STATUS
INTERRUPT ̲ASYNCH
CHANNEL ̲STATUS);"LTUX to
TDP
PROTOCOL ̲COMMAND ̲TYPES =
(NOT ̲IMPLEMENTED,
ENABLE ̲PROTOCOL,
OPEN ̲PROTOCOL,
CLOSE ̲PROTOCOL,
NOT ̲IMPLEMENTED,
STATISTICS ̲REQ,
STATUS ̲REQ,
DEVICE ̲STATUS ̲REQ)
VAR LDU ̲WORK ̲BUF ̲ONE,
LDU ̲WORK ̲BUF ̲TWO:
RECORD
IOC ̲BUFFER ̲PART: ARRAY(1...258) OF CHAR;
LDU ̲IO ̲BUFFER: ARRAY(1..128+2) OF CHAR;
END;
SAVE ̲LAST ̲OUTPUT:
RECORD
LENGTH: INTEGER
BUF : ARRAY (1..128) OF CHAR;
END;
LDU ̲OUTPUT ̲REC: ARRAY (0..127) OF CHAR;
LDU ̲OUTPUT ̲REC ̲1,
LDU ̲OUTPUT ̲REC ̲2: ARRAY (1..390) OF CHAR;
IOC ̲REC ̲LGTH: INTEGER; "save last IOC ̲REC ̲LGTH
SEND ̲DATA ̲BUF ̲ADDR,
SEND ̲DATA ̲BUF ̲LGTH: INTEGER;
I̲O̲C̲ ̲R̲E̲C̲O̲R̲D̲ ̲a̲n̲d̲ ̲L̲D̲U̲ ̲R̲E̲C̲O̲R̲D̲ ̲f̲o̲r̲m̲a̲t̲s̲;̲
IOC ̲RECORD:
HEADER IOC ̲REC ̲CONTENTS
byte 1: RS (hex 1E)
byte 2: length of contents (max 80 for
output max 255 for input to TDP)
byte 3: type (refer to IOC ̲TYPE ̲OF ̲REC).
LDU:
data.
sequence no if LDU of entire-type or start-type
LDU-type (refer to LDU ̲RECORD ̲TYPES).
4.1.5 C̲o̲m̲m̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
4.1.5.1 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲E̲R̲R̲O̲R̲ ̲M̲E̲S̲.̲
4.1.5.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
ERROR ̲MES is a common error handling routine.
Error messages are transferred to VDU ̲HANDLING for
display on operator VDU. If a fatal error and completion
code not equal to zero, then the completion code is
displayed too.
Depending on the transferred parameter-ACTION, ERROR
̲MES terminates the processing (FATAL), ships rest of
record (MSG ̲ERROR), ships rest of function (SKIP ̲RECORD)
or takes no further action (MSG ̲NOACT) after displaying.
4.1.5.1.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
ERROR ̲MES (R1,R3,R4,R5,R7,R6);
R1 c k, ACTION
R3 c k, message pointer
R4 c k, index to position in IOC-record
R5 c k, pointer to IOC record buffer
R6 c -, link.
R4 & R5 only used when ACTION = MSG ̲ERROR or SKIP ̲ERROR.
4.1.5.1.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
N/A
4.1.5.1.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
N/A
4.1.5.2 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲O̲N̲V̲ ̲A̲S̲C̲I̲I̲H̲E̲X̲ ̲T̲O̲ ̲B̲I̲N̲
4.1.5.2.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Converts one to four (consecutive) characters, representing
a HEX-number (in ASCII-representation) into binary.
Ex. "F2" represented binary as 0100 0101 0011 0010
(4532 inhex) is converted to 0000 0000 1111 0010
(00F2 in hex).
4.1.5.2.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
CONV ̲ASCIIHEX ̲TO ̲BIN (R1,R2,R4,R5,R7,R6).
R1 - R, result converted number
R2 C D, no. of characters to convert
R4 C R, index to first char., updated on exit
R5 C K, pointer tochar.buffer containing the characters
to convert.
R7 - R, completion code
R6 C -, link.
4.1.5.2.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
N/A
4.1.5.2.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
N/A
4.1.5.3 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲O̲N̲V̲ ̲A̲S̲C̲I̲I̲D̲E̲C̲ ̲T̲O̲ ̲B̲I̲N̲
4.1.5.3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Converts one to four (consecutive) characters, representing
a decimal number (in ASCII-representation) into binary.
Ex. "391" represented binary as 0011 0011 0011 1001
0011 0001 (333931 in hex) is converted to 0000 0001
1000 0111 (187 in hex).
4.1.5.3.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
CONV ̲ASCIIDEC ̲TO ̲BIN (R1,R2,R3,R4,R5,R7,R6);
R1 - R, converted number
R2 C D, no. of char. to convert
R3 - K, work
R4 C R, index to first char. to convert-updated
R5 C K, pointer to char.-buffer
R7 - R, completion code: (ok, not-ok)
R6 C D, link.
4.1.5.3.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
N/A
4.1.5.3.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
N/A
4.1.5.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲H̲E̲X̲
4.1.5.4.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Converts an integer in binary form to 1 to 4 hax-characters
(in ASCII-representation).
Reverse to CONV ̲ASCIIHEX ̲TO ̲BIN.
If fewer than 4 characters are requested, extraction
will progress from least to most significant digits.
Ex: Extraction of 2 chars.from 0100 0001 0001 1111=(411F
hex) will give 0011 0001 0100 0101 (31 45 hex).
4.1.5.4.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
HEX (R1,R2,R3,R5,R6);
R1 C D, no. of hex digits requested
R2 C K, byte offset in result buffer (start)
R3 C D, value to convert
R5 C K, pointer to result buffer
R6 C -, link.
4.1.5.4.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
N/A
4.1.5.4.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
N/A.
4.1.5.5 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲E̲C̲H̲E̲X̲
4.1.5.5.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Converts an integer in binary form to 1 to 5 decimal-characters
(in ASCII-representation).
Reverse to CONV ̲ASCIIDEC ̲TO ̲BIN.
Extraction will progress from least to most significant
digits.
Ex: Extraction of 2 chars. from 0100 0001 0001 1111
= (16671 dec) = (411 Fhex) will give 0011 0111 0011
0001 (3731 hex).
4.1.5.5.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
DECHEX (R1,R2,R3,R5,R6).
R1 C D, no. of digits to extract
R2 C K, start byte offset in result buffer
R3 C D, value to convert
R5 C K, pointer to result buffer
R6 C -, link
4.1.5.5.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
N/A
4.1.5.5.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
N/A
4.1.5.6 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲o̲m̲p̲a̲r̲e̲ ̲B̲y̲t̲e̲s̲
4.1.5.6.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Compare two buffers, byte for byte, from left to right.
Only the requested number of bytes is compared, that
is exceeding bytes in the buffers will have no influence
on the result !
Result will be
EQUAL - Correspondance in buffers up to and
including last requested buffer.
LESS - A byte in first buffer is less than
the corresponding byte in second buffer,
according to ASCII colating sequence
(binary equivalent).
GREATER - See LESS above, first buffer greater
than second.
4.1.5.6.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
COMPARE ̲BYTES (R1,R2,R5,R7,R6);
R1 C K, no.of bytes to compare
R2 - R, result (EQUAL, LESS, GREATER)
R5 C K, pointer to buffer-1
R7 C K, pointer to buffer-2
R6 C -, link
4.1.5.6.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
N/A
4.1.5.6.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
N/A
4.1.6 G̲l̲o̲b̲a̲l̲ ̲D̲a̲t̲a̲
N/A
4.1.7 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
4.1.7.1 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The external interfaces for the TDP package is interfaced
to the operator VDU and/or command file. A detail description
of the interace is given below:
% FK (fk)
The function key is sent to CAMPS. The execution awaits
CAMPS output Enable Data Keys.
% Verify (split no.)(line no.)
(column)(expected content)
It is verified that line, column and subsequent split
locations contain expected content, if not skip to
next function.
% Time (hour)(minute)(seconds)
Start of simulation at time, hour, minute.
Continuation of simulation is postponed until time
is hour, minute.
% Delay (seconds)
Continuation of simulation is resumed after (seconds)
seconds elapsed time.
% Label (label)
A dummy command for identification of a position in
the command file.
% Repeat (label)
Current file is scanned from the beginning searching
for label. If label is not found the execution of the
command file is stopped.
% DATA(split)(line)(column)(contents)
(contents) are placed in split memory starting
at position according to (split),(line) and (column).
% Stop (message):"message is optional.
The simulation is stopped.
New input is awaited on current input (operator VDU).
Message is printed on current output (operator VDU).
% Terminate
The execution of the simulator is terminated (process
killed) for this VDU simulation.
(split no): ((0,1 or 2))
(line no): = number
(number): = 1..65535
(column): = 1..80
(string): = (printable characters without spaces)
/ "(printable characters except")"
4.1.7.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲f̲a̲c̲e̲
The TDP package interface to TMS and FMS byu using
IOS calls for a detail description refer
CPS/SDS/028 (I/O Control)
CSS/4200/PSP/0035 (DAMOS I/O System
4.1.7.3 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
F̲r̲o̲m̲ ̲V̲D̲U̲ ̲S̲i̲m̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲t̲o̲ ̲S̲c̲r̲i̲p̲t̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲
1. Start Up Command (START-UP)
2. Stop Command (CLOSE-DOWN)
3. New Command request (RERD-COMMAND)
4. VDU Output delivery (VDU-HANDLING)
F̲r̲o̲m̲ ̲S̲c̲r̲i̲p̲t̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲t̲o̲ ̲V̲D̲U̲ ̲S̲i̲m̲ ̲C̲o̲n̲t̲r̲o̲l̲
1. Start Up-CC
2. Stop-CC
3. Command delivery
F̲r̲o̲m̲ ̲V̲D̲U̲ ̲s̲p̲l̲i̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲t̲o̲ ̲V̲D̲U̲ ̲S̲i̲m̲ ̲C̲o̲n̲t̲r̲o̲l̲
1. Signal semaphore "CAMPS-OPERATION"
F̲R̲O̲M̲ ̲V̲D̲U̲ ̲S̲i̲m̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲t̲o̲ ̲V̲D̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲I̲/̲F̲
1. Output data request
F̲r̲o̲m̲ ̲V̲D̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲I̲/̲F̲ ̲t̲o̲ ̲L̲o̲g̲
1. Log request
F̲r̲o̲m̲ ̲V̲D̲U̲ ̲S̲p̲l̲i̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲t̲o̲ ̲V̲D̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲I̲/̲F̲
1. Data delivery (output data)
F̲r̲o̲m̲ ̲V̲D̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲I̲/̲F̲ ̲t̲o̲ ̲V̲D̲U̲ ̲S̲p̲l̲i̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲
1. Data delivery (input data)
4.2.1 S̲c̲r̲i̲p̲t̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The Script Command Control Subpackage includes start
up/close down of files and VDU, read commands and data
from files (or VDU) and write messages to VDU.
4.2.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The functions of the Script Command Control Subpackage
are divided into six main functions and several subfunctions.
The mainfunctions are listed below and in fig 4.2.1.1-1
a functional breakdown is shown
1) Open/Close files
2) Read Script Commands
3) Read Data
4) Store Data
5) Read from VDU
6) Write to VDU
FIGURE 4.2.1.1-1
Functional Breakdown
In the Script Command Handling Module is implemented
the functions
- Read Script Commands
- Read Data
- Store Data
In the Start Up/Close down Handling Module is implemented
the function
- Open/Close files
And in the VDU Handling Module is implemented the functions
- Read from VDU
- Write from VDU
4.2.1.1.1 O̲p̲e̲n̲/̲C̲l̲o̲s̲e̲ ̲f̲i̲l̲e̲s̲
During start up of the TDP package a Start Up procedure
is called from main module. The procedure opens a command
and a data file. Further a stream to the VDU is opened.
4.2.1.1.2 R̲e̲a̲d̲ ̲S̲c̲r̲i̲p̲t̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
A command is read from the command file and validated.
If the command is for internal use it will be executed.
Otherwise the command will be delivered to the VDU
Simulator Control Subpackage.
4.2.1.1.3 R̲e̲a̲d̲ ̲D̲a̲t̲a̲
In the command record read from the command file data
are identified. If the data are in the command record
it will be read from there. Otherwise the data are
read from the datafile.
4.2.1.1.4 S̲t̲o̲r̲e̲ ̲D̲a̲t̲a̲
The data read either from datafile or command record
are validated. Data can be stored in the screen buffers
delivered to the VDU Simulator Control Subpackage or
written on the VDU.
4.2.1.1.5 R̲e̲a̲d̲ ̲f̲r̲o̲m̲ ̲V̲D̲U̲
During start up the operator specifies a command file
name and a data file name which are read from the VDU.
Futher the operator during the test run can enter commands
from the VDU.
4.2.1.1.5 W̲r̲i̲t̲e̲ ̲t̲o̲ ̲V̲D̲U̲
Before the operator can enter from the VDU as described
above he is requested for input. When commands, containing
messages, are fed from the command file, the messages
will be written on the VDU. When errors are detected
during test run, error messages are written on the
VDU.
4.2.1.1.5 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
Refer to section 2.2.2.1.1 and 4.2.1.4.1
4.2.1.1.6 E̲r̲r̲o̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
Refer to section 2.2.2.3
4.2.1.1.7 C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲
Refer to section 2.2.2.1.3 and 4.2.1.4.4
4.2.1.2 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The Script Command Control Subpackage is part of the
main process performing the functions described in
section 4.2.1.1.
The Script Command Control Subpackage consist of four
main procedures as listed below, to be called from
the VDU Simulator Control Subpackage, and several procedures.
- Start Up
- Script Command
- VDU Command
- Close Down
The subpackage is divided into four modules as shown
in fig. 4.2.1.2-1.
S̲t̲a̲r̲t̲ ̲U̲p̲ ̲M̲o̲d̲u̲l̲e̲
This module open stream to VDU, open files and initialize
registers and variables.
Fig. 4.2.1.2-2 Software Structure
S̲c̲r̲i̲p̲t̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
All Command and Data relevant functions are implemented
in this module.
V̲D̲U̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
Reading from - and writing to VDU are implemented in
this module.
C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ ̲M̲o̲d̲u̲l̲e̲
This module write a close down message to the VDU,
close files and close stream to the VDU.
4.2.1.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲e̲
The Data Flow is described in section 4.2.1.4.
4.2.1.4 M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.1.4.1 S̲t̲a̲r̲t̲ ̲U̲p̲ ̲M̲o̲d̲u̲l̲e̲
4.2.1.4.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
During start up of the TDP package the start up module
is called from the VDU Simulator Control Subpackage.
Registers and variables are initialized. A stream to
the VDU is opened . Parameter file is opened and read
(it contains command file name and data file name to
be used in the test run).
The command file and data file are opened.
Data identification as the data file is read and a
data id. table is build up.
4.2.1.4.1.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
Call specification: START UP (R7, R6);
R7 - R completion code (OK, NOT OK),
R6 C - Link.
The module interfaces to the VDU Simulator Control
Subpackage by a procedure call.
Please refer to section 4.2.1.7.
4.2.1.4.1.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Start-Up
It is the main and the only procedure of the module.
Start-Up initiallizes the subpackage, opens stream
to the VDU, opens command - and data file and builds
up a data ID table.
4.2.1.4.1.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
No specific module data are identified for this module.
Please refer to section 4.2.1.5.
4.2.1.4.1.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The flows are described shortly in this section
1) M̲a̲i̲n̲ ̲F̲l̲o̲w̲ (Start-Up)
Description: Refer to fig. 4.2.1.4.1.5-1
Initialize, Registers and variables are initialized.
Open stream VDU. Stream to the VDU is opened.
Open and read parameter file - get file names for
command- , data- and log-file.
Command file is opened.
Data file is opened.
Return to calling subpackage (SIM-CONTROL).
L̲i̲s̲t̲ ̲o̲f̲ ̲F̲l̲o̲w̲s̲
1) Mainflow (Start-Up).
Refer to source listing of SCR-CONTROL.
4.2.1.4.2 S̲c̲r̲i̲p̲t̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
4.2.1.4.2.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
A command is read from the command file and validated.
The command is either for internal- or external use.
Data belonging to the command is read from the data
file or from the command record.
The command for internal use is executed which means
Label Table updating, Repeat Stack updating of message
writting on the VDU. The command for external use is
stored in the command deliver record to be used of
the VDU Simulator Control Subpackage. Data belonging
to the external command is stored in split memory,
command deliver record or written on the VDU.
4.2.1.4.2.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
The interface is a proceduce call from VDU Simulator
Control Subpackage. Please ref. to section 4.2.1.7.
Call: SCRIPT-COMMAND (R0, R1, R7, R6)
R0 - R no of data characters
R1 - R command type
R7 - R completion code (OK, NOT-OK)
R6 C - link
4.2.1.4.2.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Script command is the main procedure of the module
which is called from the VDU Simulator Control Subpackage
Script Command reads a command from the command file,
validates it and takes further action depending on
the command.
Read-Command-File
A command is read from the command file.
Label Name
The label name is read and the Lable Table is updated.
The Test Flag is reset (0)
End Name
The end-name is read and checked against the Label
Table. After that a jump on file position to label
point or continue point is performed. Test Flag is
reset.
Repeat-Name
The label name is read. The Repeat Stack is updated
and Repeat Level is incremented. Test Flag is reset.
Message
The message content is read and written on the VDU.
Test Flag is reset.
Stop-Terminate
Read the message content and write it on the VDU. Test
Flag is set.
Verify
Data ID is read. File position is read from the Data
ID Table and data are read from the Data/command file.
The data are stored in the command deliver record.
Test Flag is set.
Data
The Data is read. file position is read from the Data
ID Table. The data are read from the data file and
stored in split memory. Test Flag is set.
Other Command
Data are read from the command record and written to
the command deliver record. Test Flag is set.
4.2.1.4.2.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Refer to …02…SCC-PRX's.
Further data refer to section 4.2.1.5.
Refer furthermore to section 4.1.4 for description
of commen-data.
4.2.1.4.2.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
Only main structure of entry-print procedure is shortly
described. For description of procedure subordinate
to this - refer to source listing of SCR-CONTROL.
S̲c̲r̲i̲p̲t̲ ̲C̲o̲m̲m̲a̲n̲d̲
COMPL-CODE: = OK;
TEST-FLAG: = RESET;
REPEAT-READ-COMMAND-FILE;
IF COMPL-CODE = NOT-OK THEN EXIT;
CASE command-type of
CLABEL: LABEL-NAME;
CEND: END-NAME;
CREPEAT: REPEAT-NAME;
CMESSAGE: MESSAGE-OUT;
CSTOP:
CTERMINATE: STOP-TERMINATE;
CVERIFY: VERIFY;
CDATA: SCR-DATA;
Otherwise OTHER-COMMAND ("commands" not executed there),
UNTIL TEST-FLAG = SET;
R0: = CMD-REC. D-COUNT;
R1: = CMD-DELIVER-REC. CMD;
R7: = COMPL-CODE;
Return to caller (Sim-CONTROL).
4.2.1.4.3 V̲D̲U̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
4.2.1.4.3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲e̲r̲i̲p̲t̲i̲o̲n̲
A command for VDU handling is received and validated.
Is it a Read command, a request for VDU command is
displayed on the VDU. When the operator has entered
the command it is read and delivered to the caller.
If the command is a Write - VDU, a message is written
on the VDU.
4.2.1.4.3.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
Call: VDU-HANDLING (R5, R7, R6);
R5 C - message pointer
R7 - R completion code
R6 C - link;
CMD-VDU C - command type WRITE VDU, READ COMMAND);
4.2.1.4.3.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
VDU-Handling
This is the main procedure of the module.
VDU-Handling receives a command from the caller, validates
it and takes further action depending on the command.
Write-VDU
A message is written on the VDU.
Read-Command
Request for command is written on the VDU. When entered
the command is read.
4.2.1.4.3.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Refer to SCC-PRX for common data. Further refer to
4.2.1.5.
4.2.1.4.3.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
Refer to SCR-CONTROL Source.
4.2.1.4.4 C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ ̲M̲o̲d̲u̲l̲e̲
4.2.1.4.4.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Has the TDP package process to be terminated the close
down module is called from the VDU Simulator Control
Subpackage.
Command- and data file are closed and a terminate message
is written on the VDU.
Futher the stream to the VDU is closed.
4.2.1.4.4.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲d̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
This module call the VDU Handling module by the procedure
call VDU-Handling (Write-VDU).
Further the module interfaces to the VDU Simulator
Control Subpackage by a procedure call.
Please refer to section 4.2.1.7
Call: CLOSE-DOWN (R7, R6);
C R7 - completion code
C R6 - link;
4.2.1.4.4.2 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Close Down
It is the only procedure of the module.
Close Down terminates the subpackage by closing files
and stream to the VDU.
4.2.1.4.4.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
No specific module data is identified for this module.
Refer to section 4.2.1.5.
4.2.1.4.4.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The flow is described shortly in this section
1) Main Flow (Close Down)
- Command file is closed
- Datafile is closed
- Process VDU-Command, Terminate message is written
on the VDU
- Stream to the VDU is closed
- Return to the caller
L̲i̲s̲t̲ ̲o̲f̲ ̲F̲l̲o̲w̲s̲
Refer to SCR-CONTROL source.
4.2.1.5 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
Refer to SCC-PRX source.
4.2.1.6 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
For the Script Command Control Subpackage there is
no common procedures.
4.2.1.7 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The VDU Simulator Control Subpackage SIM-CONTROL interfaces
to the Script Command Control Subpackage by using four
procedure calls
- Start Up
- Scpipt Command
- VDU Handling
- Close Down
Furthermore ERROR-MES calls VDU-HANDLING.
For a detailed description refer section 4.2.1.4.
Common data is found in section 4.1.4.
4.2.2 S̲i̲m̲u̲l̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
4.2.2.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Simulation Control, contains the overall control of
flow in the TDP. The subpackage initializes buffers,
variables and semaphores, calls open module and read
command module in script command subpackage, executes
commands and controls the final close down.
The VERIFY Command can result in an error generation.
An error message is transferred to VDU-Handling in
Script command subpackage.
Generally, all calls to standard DAMOS packages, result
in an error. Processed as above but the simulation
is terminated.
Asynchroneous reports (received in VDU split control)
will result in an error message and termination of
simulation.
Figure 4.2.2.1-1
Figure 4.2.2.1-2
Figure 4.2.2.1-3
Figure 4.2.2.1-4
4.2.2.2. S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
Simulation Control is divided in three modules - Initialization,
Function selection and Termination.
The subpackage has no procedures common to the modules:
Flows - see next page.
Figure 4.2.2.2-1
4.2.2.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The modules in Simulation control are functionwise
separated, and there are no interaction between the
modules.
Module descriptions - see 4.2.2.4.1 - 4.2.2.4.3.
Simulation control logic:
Initializations
Call read command (in script command sp.)
while more commands do
case command =
FK: do Function key;
VERIFY: do Verify response;
TIME: do Delay until;
DELAY: do Delay seconds;
DELAYFACTOR: do Delay factor;
STOP: do Breakpoint;
TERMINATE: do Term Simulation;
PASSWORD: do Save-ID;
Command: do Set up command;
Queue: do Empty queues;
Caseend
Call read command (in Script command sp).
Endwhile
Terminate
4.2.2.4 M̲o̲d̲u̲l̲e̲ ̲s̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
Simulation Control is divided into three modules -
Initialization (4.2.2.4.1)
Flow control Func. selec) (4.2.2.4.2)
Termination (4.2.2.4.3)
4.2.2.4.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲-̲M̲o̲d̲u̲l̲e̲
4.2.2.4.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Functions:
Allocate buffers
set-up variables (common to package)
init. variables (common to package)
init semaphores
initial signal to coroutines
call to open files and VDU
Open protocols/channels (SSC functions). (Assign devices
etc.)
4.2.2.4.1.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
Call specification:
SIM-CONTR-INIT (R6)
Registers:
R6 C - link
Other - - destroyed.
4.2.2.4.1.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
The modules are divided in three logically separated
parts
a) simple variable set-up and initializations
b) semaphore/coroutine init
c) SSC-functions (assign/open devices)
Point a) above - refer to 4.2.2.4.1.1 and detail description
4.2.2.4.1.5.
Below mentioned semaphores are set up:
Time-Signal,
CMD-file-read,
Hanging-IO,
CAMPS-operation,
Wait-VDU,
FK-sent,
Initial-sew,
Send-to CAMPS, (semaphores)
SSC-functions:
Assign STI
Create subdevices
Open channel
Enable protocol
Open protocol
4.2.2.4.1.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
An global data see 4.1.4
Data local to the subpackage
"SIMULATION CONTROL" .. see 4.2.2.4.2.4 & 4.2.2.4.3.4.
Refer to TDS-PRX and SIM-PRX.
4.2.2.4.1.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
Initialize variables common to the package - refer
to 4.1.4 for description.
Set up and initialize data common to the subpackage
- SIMULATION CONTROL - refer to 4.2.2.4.2.4 and 4.2.2.4.3.4
for detailed description.
Initialization of semaphores and sync. elements:
SSC-setup of structures.
Refer to sources -
TDP-STI.S
TDP-LTUX.S
TDPllVDU.S.
Main Flow: see next page.
M̲a̲i̲n̲ ̲F̲l̲o̲w̲ ̲(̲h̲i̲g̲h̲ ̲l̲e̲v̲e̲l̲)̲ ̲o̲f̲ ̲S̲I̲M̲-̲I̲N̲I̲T̲
T̲D̲P̲-̲S̲T̲I̲
Open local files.
Create and catalog IOS-sync-el.
Create Dummy sync-el.
Assign-STI.
Create-Subdevice-TIA
Write files to next level
Send FDCB-IX to TDP-LTUX.
Close local files.
Wait forever (on dummy sync-el).
T̲D̲P̲-̲L̲T̲U̲X̲
Open local files.
Create dummy-sync-el
Get IOS-sync-el.
Get FDCB-IX (TIA) from TDP-STI.
Create Subdevice LTUX
Save FDCB-IX (TIA) from TDP-VDU.
Write local files for next (lower) level.
Close local files.
Wait forever (dummy sync-el).
T̲D̲P̲-̲V̲D̲U̲
Open local file
Open CMD/DATA/LOG-file (START-UP)
Get FDCB-IX from TDP-LTUX.
Create sync-el for RTC (time).
Initialize split memory.
Initialize semaphores and coroutines.
Create subdevice VDU.
Open channel.
Enable protocol.
Open Protocol.
Initial CAMPS-syncronization.
Return to caller (SIM-CONTROL main).
4.2.2.4.2 Flow Control (func. selection-main)
4.2.2.4.2.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Initializations refer to 4.2.2.4.1.
Error functions control transferred to Script Command
Subpackage with error message to be displayed on VDU,
for manual interaction.
Normal operation:
Call of Initialization and Termination modules.
A command record is read (via call to Read command
in Script command sp) and interpreted. The command
functions are then executed according to the command
set-up. (Functions: see control logic in 4.2.2.3).
Depending on the function, a common variable will be
set up, a monitor procedure will be called or another
module in the package will be invoked, via call or
semaphore signal.
Further details: see description for each function.
4.2.2.4.2.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
Main module - none.
4.2.2.4.2.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Refer to control logic in 4.2.2.3.
F̲u̲n̲c̲t̲i̲o̲n̲-̲k̲e̲y̲: Function keys are converted to
the corresponding key code, and
Function-key-send is called, where
the key code is packed in LDU-format
(interrupt) and sent to CAMPS.
Coroutine is waiting upon reaction
from CAMPS.
V̲e̲r̲i̲f̲y̲-̲r̲e̲s̲p̲o̲n̲s̲e̲: Screen memory is compared against
an expected content, and an error
message is displayed (via Script
command SP) if NE (furthermore
SIM control searches ahead until
next command type).
D̲e̲l̲a̲y̲ ̲u̲n̲t̲i̲l̲: A delay until a certain point
in time is invoked.
D̲e̲l̲a̲y̲ ̲s̲e̲c̲o̲n̲d̲s̲: A delay, a certain no. of seconds,
is invoked.
D̲e̲l̲a̲y̲ ̲f̲a̲c̲t̲o̲r̲: Variable DELAY-FACTOR is updated.
Delay factor is multiplied by
delay seconds to give complete
delay period.
B̲r̲e̲a̲k̲p̲o̲i̲n̲t̲: A message is shown on operators
console, and the test can be continued
or terminated.
Calls Script command SP.
T̲e̲r̲m̲ ̲s̲i̲m̲u̲l̲a̲t̲i̲o̲n̲: Transfer control to TERMINATE
module.
S̲a̲v̲e̲ ̲I̲D̲: Save password in common variable.
S̲e̲t̲ ̲u̲p̲ ̲c̲o̲m̲m̲a̲n̲d̲: Controls send off a specific command
such as, SION, SIOF, RECV, PRNM
etc. Use proper function key for
each command.
E̲m̲p̲t̲y̲ ̲q̲u̲e̲u̲e̲s̲: Remove first element in a queue,
or remove the whole queue.
F̲u̲n̲c̲t̲i̲n̲ ̲k̲e̲y̲ ̲s̲e̲n̲d̲: Pack key code in LDU of interrupt
type and signal "SEND TO CAMPS".
Wait for response from CAMPS on
"FK-SENT".
S̲a̲v̲e̲ ̲I̲D̲: Save "Password, ID" for later
use in SION situations.
4.2.2.4.2.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Refer to TDS-PRX & SIM-PRX.
4.2.2.4.2.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
Simulation control pseudo code:
Initializations (module, see 4.2.2.4.1)
Read Command (module, see 4.2.1.4)
While more-commands do
case command =
FK: Functionkey;
VERIFY: Verify-response;
TIME: Delay-until;
DELAY: Delay-seconds;
DELAYFACTOR: Delay-factor;
STOP: Breakpoint;
TERMINATE: Term-simulation;
PASSWORD: Save-ID;
Command: Set-up-command;
QUEUE: Empty-queues;
Case end
Read command (module, see 4.2.2.4.3)
Endwhile
Terminate (module, see 4.2.2.4.3)
Function description - refer to SIM-CONTROL source.
4.2.2.4.3 T̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
This module controls termination of a TDP run with
close down and clean up.
4.2.2.4.3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The module contains or calls:
File closing (call to Script comm. control
4.2.1)
Send termination message to VDU (via Script comm. control
- 4.2.1).
Release resources (sync-elements etc.).
Stop coroutines
SSC close down functions.
4.2.2.4.3.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
Call Specifications:
R6 - link.
Other - destroyed.
no other parameters.
4.2.2.4.3.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
This module is divided in three logical parts:
SSC close down,
Coroutine clean up, and
File closing etc.
S̲S̲C̲ ̲c̲l̲o̲s̲e̲ ̲d̲o̲w̲n̲: Cleans up in TMS interface
and protocol interface by
sending close protocol, close
channel, and dismantle to
each subdevice.
C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲c̲l̲e̲a̲n̲ ̲u̲p̲: Releases resources used by
the synchronization elements.
F̲i̲l̲e̲ ̲c̲l̲o̲s̲i̲n̲g̲ ̲e̲t̲c̲.̲: Sends termination message
to VDU and calls closing routine
(CLOSE-DOWN).
4.2.2.4.3.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Global data - refer to 4.1.4.
Subpackage locals - refer to 4.2.2.5.
Local - none
Refer to TDS-PRX and SIM-PRX.
4.2.2.4.3.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
Module pseudo code:
Stop sync elements
SSC close down
Close down (module in Script comm. contr., see 4.2.1.4.4)
Refer to SIM-TERM source.
4.2.2.5 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
Modules in Simulation Control Subpackage uses data
common to the whole package - see 4.1.4.
Other commons will be described in the Flow control
module - see 4.2.2.4.2.4.
4.2.2.6 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
None.
4.2.2.7 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The Simulation Control Subpackage interfaces to Script
Command Control Subpackage by procedure calls to:
Start ̲up,
Script ̲command,
VDU ̲handling and
Close ̲down.
It interfaces to VDU split control by semaphore signalling/waiting
and transferring of data in buffer. The output data
module is called when function keys are to be sent
to CAMPS and reactions from CAMPS (via "SEND ̲TO ̲CAMPS")
are awaited before processing in simulation control
will be continued.
Refer to 4.2.2.4 and source for more details.
