top - download
⟦088f11208⟧ Wang Wps File
Length: 73679 (0x11fcf)
Types: Wang Wps File
Notes: CMS/SDS/004
Names: »4578A «
Derivation
└─⟦2e54efd14⟧ Bits:30006189 8" Wang WCS floppy, CR 0430A
└─ ⟦this⟧ »4578A «
WangText
…00……00……00……00……00…;…02…;
; ;…06…:…0c…:…00…:…02…:
: 9…0a…9…00…9…07…8…0c…8…0f…8…01…8…02…8…07…7…08…7…0d…7
6…08…6…0d…6…02…6…06…5…08…5…0b…5…0e…5…00…5…02…5…05…5…06…4…09…4…0a…4…0c…4…0f…4…00…4…05…3…0a…3…0b…3…01…3…06…2…0a…2…0d…2…00…2 1…08…1…0d…1…02……86…1 …02…
…02… …02…
…02…CMS/SDS/004
…02…840501 …02……02…
TDP PACKAGE DESIGN SPECIFICATION
…02…ISSUE 1…02…CAMPS
4.2.9 LTUX Transparent Firmware Subpackage
Specification ..........................
4.2.9.1 Functional Specification ...........
4.2.9.2 Software Structure .................
4.2.3 V̲D̲U̲ ̲S̲p̲l̲i̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲
4.2.3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
VDU split control receives IOC records or arm commands
from VDU handler IF and reacts on the commands, or
updates split memory if data.
Arm commands recognized:
- send M fields (30,#30,#5C, a, N, M)
- send first line (SO,#30,#5C, $)
- send cursor pos. (SO,#30,#5C, !)
- send one field (SO,#30,#5C, ', N)
IOC records are unpacked and contents recognized are:
Control Types:
format on (SO, A)
format off (SO, )
first line displayed (SO, $, HHHH)
delete line (SO, L)
insert line (SO, M)
cursor position (SI, column, line)
home (SO, Q)
clear split (SO, R)
clear n.characters (SO, +, G, HHH)
define field (30, (, Param, HHH)
write field (SO, %)
erase highlightes (SO, q, N)
alternate characters (SO, &, ch)
P-function keys (SO, *...)
video attribute (SO,', param)
data key enable(filter) (SO, +, I, 64 hex keycodes)
select split host & VDU (SO, +, (v)W, split no.)
lock keyboard (SO, G(
set split sizes (SO, +, S...)
unlock keyboard (SO, W)
clear all splits (SO, +, R)
request keystatus (SO, +, v)
link split (SO, +, e)
split xmit destination (SO, +, c)
data types;
type data, 1 to 80 chars.
type line, 1 to 80 chars.
type contr., formatdata possible t̲o̲ VDU
When sending data to CAMPS, this module packs the data
in LDU's and evt. in IOC records.
For detailed description of above functions refer to
VDU-manual DELTA 7260T reference manual.
4.2.3.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The module is divided in a number of procedures interpreting
one byte a time to decide the function, and a procedure
for each of the most complicated functions, among the
functions mentioned on 4.2.3.1.
CHECK 1.
BYTE
RS or SO ?
RS SO
IOC RECORD ARM COMMAND
4.2.3.2-2 4.2.3.2-4
FIGURE 4.3.4.3-1
IOC RECORD
save length
3. byte
IOC type
Data type Line type Control
type
4.2.3.2-3
FIGURE 4.2.3.2-2
IOC Record
FIGURE 4.2.3.2-3
Control Type
Interpret
arm command
Send fields
Send Cursor
position
Send first
line displayed
FIGURE 4.2.3.2-4
Arm Commands
4.2.3.3 D̲a̲t̲a̲f̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
IOC records or arm commands are received from VDU handler
interface. An IOC record of control type can consist
of several VDU functions, all starting with the character
SO (hex OE) and with a function dependent layout for
the rest of characters to the function. Format txt
possible.
Data- or line-type IOC records will each contain only
one data record.
The control logic should be obvious from the functional
description and description of software structure.
Refer to these in 4.2.3.1 and 4.2.3.2.
4.2.3.4 M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.3.4.1 V̲D̲U̲ ̲S̲p̲l̲i̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲M̲a̲i̲n̲ ̲M̲o̲d̲u̲l̲e̲
VDU split control consists of two modules with procedures
for each function, described in 4.2.3.1. Divided only
caused by size of the modules - no logical division
required
4.2.3.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̲
Refer to 4.2.3.1 for functions.
The module will call IOC/LDU pack routine which will
call the send routine to send data or answers to CAMPS.
E̲r̲r̲o̲r̲s̲:
Unrecognizable characters or functions will result
in an error message to the VDU. Split control will
then try to find the next "good" records, skipping
the rest of the error prone record.
4.2.3.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: DATA ̲ENTRY ̲INT (R3,R4,R5,R7,R6);
R3 C - points to first char in IOC-rec-header
R4 C - IOC-rec-lgth+lgth of header (3)
R5 C K address of IOC-rec-buffer
R7 - R completion code (OK, NOT ̲OK)
R6 C - link
Called from VDU ̲IF only.
4.2.3.4.1.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Short description of each m̲a̲i̲n̲ procedure in the module
(utility procedures not described):
D̲A̲T̲A̲ ̲E̲N̲T̲R̲Y̲ ̲I̲N̲T̲E̲R̲P̲R̲E̲T̲A̲T̲I̲O̲N̲ is the main procedure called
from the subpackage VDU ̲HANDLER ̲IF.
The procedure calls IOC ̲REC ̲IN or ARM ̲COM ̲IN depending
on first character in the record (RS or SO).
I̲O̲C̲ ̲R̲E̲C̲ ̲I̲N̲ interprets IOC record headers, saves IOC
record length and identifies the types data, line and
control. It calls procedures DATA ̲REC ̲IN, LINE ̲REC
̲IN or CONTROL ̲REC ̲IN depending on the type.
A̲R̲M̲ ̲C̲O̲M̲ ̲I̲N̲. Arm commands and poss. split select record
are identified for further interpretation.
D̲A̲T̲A̲ ̲R̲E̲C̲ ̲I̲N̲ places data in split memory. Only non format
mode.
L̲I̲N̲E̲ ̲R̲E̲C̲ ̲I̲N̲ places data in split memory as above and
changes to next line after the update of split memory.
Only non format mode.
C̲O̲N̲T̲R̲O̲L̲ ̲R̲E̲C̲ ̲I̲N̲ interprets first character of a control
function and selects procedure for further interpretation.
I̲O̲C̲ ̲S̲H̲I̲F̲T̲ ̲O̲U̲T̲ ̲T̲Y̲P̲E̲ interprets the next (second) character
of the control record above if it is a shift out type.
F̲I̲R̲S̲T̲ ̲L̲I̲N̲E̲ ̲D̲I̲S̲P̲L̲A̲Y̲E̲D̲ validates and accepts a new first
line displayed.
D̲E̲L̲E̲T̲E̲ ̲L̲I̲N̲E̲ deletes a line in split memory and moves
all lines below the deleted line up.
I̲N̲S̲E̲R̲T̲ ̲L̲I̲N̲E̲.̲ An empty line is inserted before current
line and all lines below are pushed down.
C̲U̲R̲S̲O̲R̲ ̲T̲O̲ ̲H̲O̲M̲E̲.̲ Moves current cursor home and adjust
first line displayed.
C̲L̲E̲A̲R̲ ̲S̲P̲L̲I̲T̲.̲ One split or all splits are cleared and
all fields to the split(s) are released.
S̲O̲ ̲P̲L̲U̲S̲ ̲T̲Y̲P̲E̲. Identification of extended shift out
functions. These are further interpreted.
D̲E̲F̲I̲N̲E̲ ̲F̲I̲E̲L̲D̲.̲ A new field format validated and saved
if OK.
W̲R̲I̲T̲E̲ ̲T̲O̲ ̲F̲I̲E̲L̲D̲.̲ The function is identified but not
implemented. Error message will be sent. Not fatal.
V̲I̲D̲E̲O̲ ̲A̲T̲T̲R̲.̲ As for WRITE ̲TO ̲FIELD.
S̲E̲N̲D̲ ̲F̲I̲E̲L̲D̲S̲.̲ Reaction on the arm command - send fields.
The number of fields requested are packed in IOC records
ready for send. Calls SEND ̲TO ̲CAMPS (OUTPUT ̲DATA).
S̲E̲N̲D̲ ̲V̲D̲U̲ ̲F̲I̲R̲S̲T̲ ̲L̲I̲N̲E̲.̲ Arm command identified and first
line displayed is packed in IOC record for send before
calling SEND ̲TO ̲CAMPS.
S̲E̲N̲D̲ ̲V̲D̲U̲ ̲C̲U̲R̲S̲O̲R̲ ̲P̲O̲S̲.̲ Arm command identified. Cursor
position and line number are packed in IOC record before
calling SEND ̲TO ̲CAMPS.
C̲L̲E̲A̲R̲ ̲N̲ ̲C̲H̲A̲R̲S̲.̲ A number of characters in split memory
is cleared.
L̲I̲N̲K̲ ̲S̲P̲L̲I̲T̲.̲ Identified, but not implemented. Error
message "not implemented" send to VDU.
C̲H̲A̲N̲G̲E̲ ̲S̲P̲L̲I̲T̲.̲ Host split number is positioned.
D̲A̲T̲A̲ ̲K̲E̲Y̲ ̲E̲N̲A̲B̲L̲E̲. Keyboard filter is received, but ignored.
No error message.
K̲E̲Y̲L̲O̲C̲K̲ ̲S̲T̲A̲T̲U̲S̲ ̲R̲E̲Q̲U̲E̲S̲T̲.̲ Responds to request of keylock
status. The respond is an LDU of interrupt type, ITL
with the hardware (always unlocked) and the software
keylock status.
S̲E̲T̲ ̲C̲U̲R̲S̲O̲R̲ ̲P̲O̲S̲I̲T̲I̲O̲N̲.̲ Column and line number are converted
to current cursor position.
4.2.3.4.1.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Refer to TDS-PRX and VDU-PRX.
Local Data:
Type
IOC ̲REC ̲BUF : array(1..1) of char;
IOC ̲T=(N ̲DATA,N ̲LINE,N ̲SP1,N ̲SP2,N ̲CONT)
VAR
IOC ̲TYPE ̲OF ̲REC : IOC ̲T;
BUF ̲LENGTH : INTEGER;
IT ̲LDU : array(1..5) of char;
NOT ̲FOUND : BOOLEAN;
CONST
SOFTKEY ̲LOCKED = #41; "hardkey unlocked
SOFTKEY ̲UNLOCKED = #40; "hardkey unlocked
RS = #1E; "record separator
4.2.3.4.1.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
Only main structure shown. For details refer to
VDU ̲SPLIT1 & VDU ̲SPLIT2 sources.
Case first char. in buffer of
RS: "IOC record
Case third char. in buffer of
DATA: put data chars;
LINE: put line chars;
CONT: interpret control chars;
otherwise msg.error "bad IOC";
SO: "arm command
Select split
Validate arm command
case first char in arm command of
"a": interpret send fields;
"'": interpret send one field;
"$": send VDU first line;
"!": send VDU cursor pos;
otherwise msg ̲error "bad arm";
otherwise msg ̲error "unknown function";
Return.
4.2.3.5 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
All data common - refer to 4.2.3.4.1.4.
4.2.3.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.4 V̲D̲U̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲I̲/̲F̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This subpackage handles the interface to the VDU Handler
package (Transparent VDU handler & TDSLTUX ̲FW).
4.2.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̲
The function of the VDU Handler I/F subpackage is divided
into two main functions and some subfunctions. The
main functions are
1) LDU Transfer
2) LDU Unpacking
In fig. 4.2.4.1-1 is shown a functional breakdown.
FIGURE 4.2.4.1-1
Functional Breakdown.
4.2.4.1.1 L̲D̲U̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲
LDU's received from VDU Handler are, after unpacking,
delivered to VDU Split Control or CONTROL ̲ENTRY ̲INT.
LDU'S from VDU Split Control are transferred to VDU
Handler.
4.2.4.1.2 L̲D̲U̲ ̲U̲n̲p̲a̲c̲k̲i̲n̲g̲
LDU's are selected between Data and Control. After
selection the LDU header is removed.
4.2.4.1.3 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
During start up of the TDP package the VDU Handler
I/F is activated by the VDU Simulator Control. The
VDU Handler I/F requests the LTUX for data and waits
until data are received.
4.2.4.1.4 E̲r̲r̲o̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
Error Reports received from the VDU Handler are delivered
to CONTROL ̲ENTRY ̲INT which takes action on the report.
4.2.4.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 VDU Handler I/F consists of two modules performing
the functions listed in section 4.2.4.1.
The Input ̲Data module is part of a coroutine further
containing the VDU ̲SPLIT ̲CONTROL module. The OUTPUT
̲DATA module is independent.
The software structure is shown in fig. 4.2.4.2-1.
FIGURE 4.2.4.2-1
Software STructure.
I̲n̲p̲u̲t̲ ̲D̲a̲t̲a̲ ̲M̲o̲d̲u̲l̲e̲
Receives LDU's from the LTUX. Unpacks the LDU's and
delivers IOC records to VDU ̲SPLIT ̲CONTROL or CONTROL
̲ENTRY ̲INT.
O̲u̲t̲p̲u̲t̲ ̲D̲a̲t̲a̲ ̲M̲o̲d̲u̲l̲e̲
Receives LDU's and transfers them to the LTUX for further
transmission.
4.2.4.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 Data Flow is described in section 4.2.4.4.
4.2.4.4 M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.4.4.1 I̲n̲p̲u̲t̲ ̲D̲a̲t̲a̲ ̲M̲o̲d̲u̲l̲e̲
4.2.4.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̲
LDU's received from CAMPS are routed to the Input ̲Data
procedure. The LTU Type is detected and the LDU is
selected between Data and Control. If the LDU contains
Data, the LDU Header is removed and the LDU is delivered
to the VDU ̲Split ̲Control.
If the LDU contains Control the Header is removed and
the LDU is delivered to the VDU ̲Split ̲Control if it
was an input request (arm command), otherwise to the
CONTROL ̲ENTRY ̲INT. All Data to/from the VDU Handler
I/F module are sent for logging.
4.2.4.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̲
No internal module interfaces in this subpackage.
4.2.4.4.1.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
This module is divided into the following procedures
- Input ̲Data (Main Procedure)
- Interpret ̲Data
- Interpret ̲Control
- Identify ̲IOC ̲REC
- Divided ̲IOC ̲REC
- Adjust ̲For ̲Divided ̲IOC
I̲n̲p̲u̲t̲ ̲D̲a̲t̲a̲
Requests for input data from the LTUX and receives
LDU's in specified work buffers. Call the Log module
for logging the LDU's. Decides further action on the
LDU's depending on the content (Data ̲Content).
I̲n̲t̲e̲r̲p̲r̲e̲t̲ ̲D̲a̲t̲a̲
Selects the LDU type and depending on the type decides
further action.
I̲n̲t̲e̲r̲p̲r̲e̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲
If control type is an input request IOC records are
delivered to the VDU Split Control, otherwise to the
CONTROL ̲ENTRY ̲INT.
I̲d̲e̲n̲t̲i̲f̲y̲ ̲I̲O̲C̲ ̲R̲E̲C̲
IOC records are delivered to the VDU Split Control.
D̲i̲v̲i̲d̲e̲d̲ ̲I̲O̲C̲ ̲R̲E̲C̲
If the IOC Record is divided in two LDU's the first
part of the IOC record is moved to another work buffer
so when the next LDU, containing the last part of the
IOC record is received the IOC record exists as entire
record, otherwise the last IOC record is delivered
to the VDU Split Control.
A̲d̲j̲u̲s̲t̲ ̲F̲o̲r̲ ̲D̲i̲v̲i̲d̲e̲d̲ ̲I̲O̲C̲
If the IOC record was divided, the now entire record
(of Divided ̲IOC ̲REC) is adjusted by the last char of
the first LDU replacing the LDU header of the second
LDU.
4.2.4.4.1.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Refer to 4.2.4.5.
4.2.4.4.1.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The flows are shortly described in this section.
1) I̲n̲p̲u̲t̲ ̲D̲a̲t̲a̲ (Main flow)
In detail ?: Refer to source.
- Append-/Read ̲Bytes. Receive an LDU from the LTUX.
- Work ̲Buffer Selection, Select/work buffer containing/to
contain current LDU and next LDU.
- Init Read ̲Bytes, Reserve a buffer for the next
LDU.
- Call Log, Send LDU for logging.
- Case LDU ̲Content ̲State, Call Interpret ̲Data (flow
2), Call Interpret ̲Control (flow 3).
- Wait (init read ̲bytes), Receive the next LDU.
- Change Read ̲Bytes ̲State, Change work ̲buffer.
- Jump to Append ̲Bytes, Request for LDU.
2) I̲n̲t̲e̲r̲p̲r̲e̲t̲ ̲D̲a̲t̲a̲
Detailed ?: Refer to source.
- Case LDU ̲Type,
Start ̲Of ̲LDU
- Check LDU ̲State, LDU ̲State = Start
Set LDU ̲State = Mid
- Save LDU ̲Seq ̲No
- Set Pointer to IOC ̲Record
- Call Identify ̲IOC ̲REC flow 4
- Call Divided ̲IOC ̲REC flow 5
Mid ̲Of ̲LDU
- Check LDU ̲State, LDU ̲State = Mid
Set LDU ̲State = End
- Call Adjust ̲For ̲Divided ̲IOC flow 6
- Call Identify ̲IOC ̲REC
- Call Divided ̲IOC ̲REC
End ̲Of ̲LDU
- Check LDU ̲State, LDU ̲State = End
Set LDU ̲State = Start
- Call Adjust ̲For ̲Divided ̲IOC
- Call Identify ̲IOC ̲REC
- Check LDU ̲Buf ̲Lgth, If OK then
Call Divided ̲IOC ̲REC else error.
Entire ̲LDU
- Check LDU-State, LDU ̲State not equal to
Start then error
- Save LDU ̲Seq ̲No
- Set Pointer to IOC ̲Record
- Call Identify ̲IOC ̲REC
- Check LDU ̲Buf ̲Lgth, If OK then
Call Divided ̲IOC ̲REC else error
Return
3) I̲d̲e̲n̲t̲i̲f̲y̲ ̲I̲O̲C̲ ̲R̲e̲c̲
D̲e̲t̲a̲i̲l̲e̲d̲: Refer to source.
- While DO, Repeat Loop Start
- Call Data ̲Entry ̲Interpretation,
Deliver IOC Record to VDU Split Control
- End while , Repeat Loop End
4) D̲i̲v̲i̲d̲e̲d̲ ̲I̲O̲C̲ ̲R̲e̲c̲
Detailed: Refer to source.
- Check last IOC Record for divided
- If divided, Move the first part of the IOC record
to the second work buffer
- Call Data ̲Entry ̲Interpretation. If not divided
the IOC record is delivered to VDU Split Control.
5) A̲d̲j̲u̲s̲t̲ ̲F̲o̲r̲ ̲D̲i̲v̲i̲d̲e̲d̲ ̲I̲O̲C̲
Details: Refer to source.
- If last IOC record was complete then exit the procedure
- If IOC record was divided, the last char from the
first part of the IOC record is inserted instead
of the LDU header of the next LDU, containing the
last part of the IOC record, for completion of
the entire IOC record.
- Call Data ̲Entry ̲Interpretation. The IOC record
is delivered to VDU Split Control.
6) I̲n̲t̲e̲r̲p̲r̲e̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲
Details: Refer to source.
- Check Control Type,
- If Input Request, Call Data ̲Entry ̲ Interpretation,
Arm Command delivered to VDU Split Control.
- Not Input Request, Call Control ̲Entry ̲In-
terpretation, Command delivered to VDU Simulator
Control.
4.2.4.4.2 O̲u̲t̲p̲u̲t̲ ̲D̲a̲t̲a̲ ̲M̲o̲d̲u̲l̲e̲
4.2.4.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̲
For transmission of data to CAMPS VDU Split Control
calls the Send ̲CAMPS procedure which transfers a whole
LDU to the VDU Handler (LTUX), for further transmission.
One LDU at a time.
4.2.4.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̲
No internal module interface in this subpackage.
4.2.4.4.2.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
This module contains only one procedure.
- Send ̲CAMPS
LDU's received from VDU Split Control are transferred
to VDU Handler (LTUX). The log module is called for
logging of the LDU's.
4.2.4.4.2.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Refer to 4.2.4.5.
4.2.4.4.2.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The flow is shortly described in this section.
1) S̲e̲n̲d̲ ̲C̲A̲M̲P̲S̲
Refer to source for details.
- LDU transferred to VDU Handler (LTUX)
- Call Log, LDU send for logging.
4.2.4.5 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Refer to TDS ̲PRX and VDUH ̲IF ̲PRX.
4.2.4.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̲
No common procedures in this subpackage.
4.2.4.7 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
This subpackage interfaces to the VDU Simulator Control
-, the VDU Split Control - and the Log Handling subpackage.
T̲o̲ ̲V̲D̲U̲ ̲S̲i̲m̲u̲l̲a̲t̲o̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲
Control ̲Entry ̲Int (Pointer, LDU ̲Buf ̲Lgth,Link)
E̲r̲r̲o̲r̲ (MSG ̲Address)
F̲r̲o̲m̲ ̲V̲D̲U̲ ̲S̲i̲m̲u̲l̲a̲t̲o̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲
Send ̲CAMPS (Pointer, Buf ̲Lgth, Link)
T̲o̲ ̲V̲D̲U̲ ̲S̲p̲l̲i̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲
Data ̲Entry ̲Interpretation (Pointer, IOC ̲Rec ̲Lgth, Link)
F̲r̲o̲m̲ ̲V̲D̲U̲ ̲S̲p̲l̲i̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲
Send ̲CAMPS (Pointer, Buf ̲Lgth, Link)
T̲o̲ ̲L̲o̲g̲
LOG ̲IO (Pointer, Buf ̲Lgth, Link).
4.2.5 L̲o̲g̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲
4.2.5.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This subpackage logs all ingoing and outgoing traffic
from/to CAMPS with sequence number and timetag.
LOG
Get Put Write to
time and date sequence No. log file
4.2.5.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
LOG
Module
LOG
Procedure
4.2.5.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
Log procedure called with buffer pointer, buffer length
and ident (in/outgoing).
Only one procedure containing:
read time and date;
convert to integer;
put hour, minute, sec, millisec. into outputrecord;
put ident;
put sequence No;
copy buffer into log record;
if buffer length ( log record put trailing #00;
write log record
return.
4.2.5.4 M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Only one module.
4.2.5.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̲
Refer to 4.2.5.1.
4.2.5.4.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
Call specification:
LOG ̲IO (R3,R4,R5,R6).
R3 C - IO ̲ID, in/outgoing
R4 C - LDU ̲Buffer ̲Lgth
R5 C - LDU ̲Buffer ̲Pointer
R6 C - link
4.2.5.4.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Only one preocedure. Refer to 4.2.5.3.
4.2.5.4.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Log ̲Record:
hour : integer;
minute : integer;
second : integer;
m ̲sec : integer;
io ̲id : integer;
io ̲no : integer;
io ̲buffer: array (1..128) of char;.
5.2.5.4.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
Refer to source list.
4.2.5.5 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲
N/A
4.2.5.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̲
N/A
4.2.5.7 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Refer to 4.2.5.4.2
4.2.6 I̲n̲t̲e̲r̲p̲r̲e̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲s̲
4.2.6.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This is a minor package, interpreting control type
LDU's from LTUX.
LDU's recognized are
reception ̲status,
transmission ̲status,
protocol ̲status and
interrupts.
4.2.6.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
4.2.6.3 D̲a̲t̲a̲f̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
Case "second character in buffer" of
0: transmission ̲status;
1: reception ̲status;
2: interrupt ̲type;
3: protocol ̲response;
case end
return;
Refer to source for details.
4.2.6.4 M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Only one module. Entry point procedure CONTR ̲ENTRY
̲INT.
4.2.6.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̲
Refer to 4.2.6.1.
4.2.6.4.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
CONTR ̲ENTRY ̲INT (R3,R4,R5,R6)
R3 C - index in buffer, of second LDU char.
R4 C - buffer length
R5 C K buffer pointer
R6 C - link.
4.2.6.4.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Refer to source.
4.2.6.4.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Refer to TDS ̲PRX,
SIM ̲PRX,
VDUH ̲IF ̲PRX.
4.2.6.4.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
Refer to 4.2.6.3.
4.2.6.5 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
N/A
4.2.6.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.7 C̲o̲m̲m̲o̲n̲ ̲W̲a̲i̲t̲i̲n̲g̲
4.2.7.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This is a low priority routine, executed when no other
coroutine is working. The general waitings upon IO
̲answers and time ̲interrupts are performed here.
When an IO operation is finished or a time interrupt
is sent, this routine receives control and signals
a semaphore, selected by operation ID from the finished
operation.
TDP is divided in 2 "independent" coroutines - see
drawing on the next page. Both coroutines contain several
waiting points.
FIGURE
4.2.7.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e
Refer to source. Only one procedure.
4.2.7.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
Refer to source.
4.2.7.4 M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
One module with only one procedure.
Known only by coroutine monitor.
Not called - executed by semaphore signalling.
4.2.7.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
N/A
4.2.7.6 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
N/A
4.2.7.7 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̲
N/A
4.2.8 O̲f̲f̲l̲i̲n̲e̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲/̲D̲a̲t̲a̲f̲i̲l̲e̲ ̲G̲e̲n̲e̲r̲a̲t̲o̲r̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This subpackage includes command/parameter validation
and command-/datafile generation.
4.2.8.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 Offline Command-/Datafile Generator
Subpackage are divided into 4 main functions and some
subfunctions. In fig. 4.2.8.1-1 is shown a functional
breakdown and below are the main functions listed.
1) Open files
2) Read from Input file
3) Validation
4) File generation
FIGURE 4.2.8.1-1
Functional Breakdown.
In the Command Reading Module is implemented the functions
- Open files
- Read Command
- Command Validation
In the Parameter Reading Module is implemented the
functions
- Read Parameter
- Parameter Validation
File generation and Error Table Generation are implemented
as common procedures.
4.2.8.1.1 O̲p̲e̲n̲ ̲F̲i̲l̲e̲s̲
During start up of the Offline Command-/Datafile Generation
subpackage input-and output files are read from the
parameter file. Input files and output files are opened.
4.2.8.1.2 R̲e̲a̲d̲ ̲F̲r̲o̲m̲ ̲I̲n̲p̲u̲t̲ ̲F̲i̲l̲e̲
Commands and the belonging parameters are read from
the input file.
4.2.8.1.3 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲
The commands and parameters read from the input file
are validated. If errors, then error messages and line
No. are stored in the error table.
4.2.8.1.4 F̲i̲l̲e̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲
If no errors in the validation of the commands and
parameters these are stored in a command file and data
file.
4.2.8.1.5 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
Refer to section 4.2.8.4.1.
4.2.8.1.6 E̲r̲r̲o̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
Errors in command and parameter specifications result
in an update of the error table. The error table is
displayed at the VDU after completion of the program
run. Completion code errors result in a termination.
4.2.8.1.7 C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲
If a completion code error occurs the process (program)
is terminated, else a termination happens at the end
of the program.
4.2.8.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 Offline Command-/Datafile Generator Subpackage
consists of one process performing the functions listed
in section 5.2.8.1.
The process consists of two software modules as shown
in fig. 4.2.8.2-1.
C̲o̲m̲m̲a̲n̲d̲ ̲R̲e̲a̲d̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
The Command Reading Module is the main module. It reads
and validates commands from input file and defines
the actions to be performed.
P̲a̲r̲a̲m̲e̲t̲e̲r̲ ̲R̲e̲a̲d̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
The Parameter Reading Module validates the parameters
belonging to the commands and decides the further action.
The module is called from the Command Reading Module.
FIGURE 4.2.8.2-1
Software Structure.
4.2.8.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 Data Flow is described in section 4.2.8.4.
4.2.8.4 M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.8.4.1 C̲o̲m̲m̲a̲n̲d̲ ̲R̲e̲a̲d̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
4.2.8.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 Offline Command-/Datafile Generator
Subpackage the input- and output file names are read
from the parameter file generated at the start of the
execution of the program. The files are opened.
The first line in the input file is read. The first
character is validated. If a command line the command
is read and the Parameter Reading module is called
if the command was valid, else a new line is read.
If the line was a comment line or an empty line a new
line is read. If the first character was a space the
Line ̲Check procedure is called. If the first character
was anything else than the above described the error
table is updated.
4.2.8.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̲
The main module is not called from other modules.
The module calls the Parameter Reading module by the
procedure call Read ̲Param /Command Name). Further the
main module calls common procedures.
4.2.8.4.1.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
This module is divided into
- The main program
- The Start ̲Up Procedure
- The Read ̲Command Procedure
M̲a̲i̲n̲ ̲P̲r̲o̲g̲r̲a̲m̲
Calls the Start Up procedure to open files. Reads a
line from the input file and validates the first character.
Selects the further action to be performed. The main
program repeats the reading from input file until end
of file.
S̲t̲a̲r̲t̲ ̲U̲p̲
The Start ̲Up procedure reads the file names from the
parameter file. It opens the input- and output files
and sets the file position on these files.
R̲e̲a̲d̲ ̲C̲o̲m̲m̲a̲n̲d̲
The Read ̲Command procedure reads the command from the
line.
4.2.8.4.1.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.
Please refer to section 4.2.8.5.
4.2.8.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̲
Description: Refer to Source PAR1.S.
- Start-Up, Open input and output files flow 2.
- Read the first line from input file.
- Case first character, Read ̲Command Line ̲Check,
continue or Error Table updating; (Read ̲Command
flow 3).
- If end of file then output Error Table on the VDU
else read next line from input file.
2) S̲t̲a̲r̲t̲ ̲U̲p̲
Description: Refer to Source PAR1.S.
File names are read from parameter file and input-and
output files are opened.
3) R̲e̲a̲d̲ ̲C̲o̲m̲m̲a̲n̲d̲
Description: Refer to Sourcr PAR1.S,
A command is read from the input file.
4.2.8.4.2 P̲a̲r̲a̲m̲e̲t̲e̲r̲ ̲R̲e̲a̲d̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
4.2.8.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̲
The Parameter Reading Module is called from the Command
Reading Module when a command is read from the input
file. The module validates the command and depending
on the command it calls a procedure for reading and
validating the parameters belonging to the command.
If the commands and parameters are valid these are
stored on the command- and data file. Otherwise the
Error Table is updated.
4.2.8.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̲
This module is called from the Command Reading Module
by the procedure call Read ̲Param.
The module itself calls the common procedures.
4.2.8.4.2.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
R̲e̲a̲d̲ ̲P̲a̲r̲a̲m̲
It is the main procedure in this module.
The procedure validates the command read from the input
file and calls a subprocedure depending on the command.
The following procedures read and validate parameters
belonging to the commands.
(̲L̲a̲b̲e̲l̲ ̲E̲n̲d̲
(̲R̲e̲p̲e̲a̲t̲
(̲T̲i̲m̲e̲
(̲D̲e̲l̲a̲y̲
(̲D̲e̲l̲a̲y̲ ̲F̲a̲c̲t̲o̲r̲
(̲F̲K̲
(̲P̲a̲s̲s̲w̲o̲r̲d̲
(̲C̲o̲m̲m̲a̲n̲d̲
(̲D̲a̲t̲a̲ , DRead ̲Content
(̲V̲e̲r̲i̲f̲y̲ , VRead ̲Content
(̲M̲S̲T̲ (Message, Stop, Terminate)
(̲Q̲u̲e̲u̲e̲
Common procedure to (Data and (Verify:
R̲e̲a̲d̲ ̲S̲p̲l̲i̲t̲ ̲N̲o̲
R̲e̲a̲d̲ ̲L̲i̲n̲e̲ ̲N̲o̲
R̲e̲a̲d̲ ̲C̲o̲l̲ ̲N̲o̲
4.2.8.4.2.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.
Please refer to section 4.2.8.5.
4.2.8.4.2.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The flows are shortly described in this section
1) M̲a̲i̲n̲ ̲F̲l̲o̲w̲ (Read ̲Param)
Description: Refer to Source PAR1.S.
- Case Command of
- Label, (2)
- End, (2)
- Repeat, (3)
- Time, (4)
- Delay, (5)
- Delay Factor, (6)
- FK, (7)
- Password, (8)
- Command, (9)
- Data, (10)
- Verify, (15)
- Message, (16)
- Queue, (17)
- Stop, (16)
- Terminate, (16)
2) L̲a̲b̲e̲l̲, E̲n̲d̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer to Source PAR1.S.
- Command is stored in command record
- Data are read, validated and stored in command
record, common procedure
- File Output, command record stored in command file,
common procedure.
3) R̲e̲p̲e̲a̲t̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer to Source PAR1.S.
- Command is stored in command record
- Label name is read and stored in command record,
common procedure
- The repeat no is read and validated, common procedure
- The repeat no is stored on common record
- File Output, command record stored on command file,
common procedure.
4) T̲i̲m̲e̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer to Source PAR1.S.
- Command is stored in command record
- The hour is read, validated and stored on the command
record
- The minute is read, validated and stored on command
record
- The second is read, validated and stored on command
record
- File Output, command record is stored on command
file.
5) D̲e̲l̲a̲y̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer to Source PAR1.S.
- Command is stored in the command record
- The no of delays is read, validated and stored
in the command record
- File Output, command record is stored on the command
file
6) D̲e̲l̲a̲y̲ ̲F̲a̲c̲t̲o̲r̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer source PAR1.S.
- The command is stored in the command record
- The delay factor is read, validated and stored
in the command record
- File Output, command record is stored on the command
7) F̲K̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer to Source PAR1.S.
- Command is stored in the command record
- The function key is read, validated and stored
in the command record
- File Output, command record is stored on the command
file.
8) P̲a̲s̲s̲w̲o̲r̲d̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer Source PAR1.S.
- Command is stored in the command record
- The password is read, validated and stored in the
command record
- File Output, the command record is stored on the
command file.
9) C̲o̲m̲m̲a̲n̲d̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer to Source PAR1.S.
- Command is stored in the command record
- The command function is read, validated and stored
in the command record
- File Output, command record is stored on the command
file.
10) D̲a̲t̲a̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer Source PAR1.S.
- The data ̲ID no is stored in the data record
- Data file position and data ̲ID no is stored in
the command record
- Command is stored in the command record
- Out file, command record is stored on the command
file
- The split no is read, validated and stored in the
data record.
- The line no is read, validated and stored in the
data record.
- The col no is read, validated and stored in the
data record.
- The data content is read, validated and stored
in the data record.
- Read a new line if more fields are specified
- Out File, the data record is stored on the data
file.
15) V̲e̲r̲i̲f̲y̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer to Source PAR1.S.
See description of data.
16) M̲e̲s̲s̲a̲g̲e̲,̲ ̲S̲t̲o̲p̲,̲ ̲T̲e̲r̲m̲i̲n̲a̲t̲e̲ ̲(̲M̲S̲T̲)̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer to Source PAR1.S.
- Command is stored in the command record
- The message is read and stored in the command record
- File Output, the command record is stored on the
command file.
17) Q̲u̲e̲u̲e̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer to Source PAR1.S.
- The command is stored in the command record
- The queue function is read, validated and stored
in the command record
- The queue parameter is read, validated and stored
in the command record
- File Output, the command record is stored on the
command file.
4.2.8.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̲
F̲l̲o̲w̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
1) E̲r̲r̲o̲r̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer to Source PAR1.S.
The error table is updated with an error message
pointer and a line no
2) L̲i̲n̲e̲ ̲C̲h̲e̲c̲k̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer to Source PAR1.S.
The line or the rest of a line is validated for
a comment line or an empty line.
3) R̲e̲a̲d̲ ̲D̲a̲t̲a̲ ̲1̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer to Source PAR1.S.
Data are read from file and validated for letter.
If letter data are stored in the command record.
4) R̲e̲a̲d̲ ̲D̲a̲t̲a̲ ̲2̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer to Source PAR1.S.
Data are read from file and validated for oversize
and limitations. If data are valid they are stored
in the command record.
5) R̲e̲a̲d̲ ̲D̲i̲g̲i̲t̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer to Source PAR1.S.
Data are read from file and validated for digits.
If data are valid a calculation is made and the
result is compared against max.size.
6) O̲u̲t̲ ̲F̲i̲l̲e̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer to Source PAR1.S.
If no errors have occurred the command record is
stored on the command file and/or the data record
is stored on the data file.
7) F̲i̲l̲e̲ ̲O̲u̲t̲p̲u̲t̲
D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲: Refer to Source PAR1.S.
The Line Check procedure is called. If no errors
on the line the Out File procedure is called for
storage of command-and/or data record.
4.2.8.7 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
This subpackage is an offline subpackage and interfaces
to SCRIPT ̲CONTROL via CMD ̲FILE & DATA ̲FILE only.
Below are shown file- and record formats for input
text editor file and for output files, CMD- & DATA
file.
T̲e̲x̲t̲ ̲E̲d̲i̲t̲o̲r̲ ̲S̲c̲r̲i̲p̲t̲ ̲F̲o̲r̲m̲a̲t̲s̲
General format:
%̲ ( script ̲command ̲id) :̲ (SP) (parameters)
(script ̲command ̲id)::=
FK/COMMAND/DATA/VERIFY/DELAY/DELAYFACTOR/
TIME/PASSWORD/LABEL/END/REPEAT/QUEUES/MESSAGE/STOP/
TERMINATE/RELEASE
(SP)::= space space
(parameters)::= (set of param) !̲(NL)(set of param)
(set of param)::= parameters depending on SCRIPT
̲COMMAND ̲ID. If several parameters
in set, delimiter is semicolon(;)
(NL):: new ̲line.
For exact format of each command ̲type refer to USER
̲MANUAL.
Since it is a text ̲editor ̲file, each record is in "free
format", variable size delimited by "NEW ̲LINE" character.
C̲M̲D̲ ̲F̲I̲L̲E̲ ̲(̲o̲u̲t̲p̲u̲t̲)̲
Fixed size records, 102 characters each.
One record type for each command type, described in
detail below.
General format:
C ̲COUNT : INTEGER;
CMD ̲NAME : ARRAY(1..11) OF CHAR;
DATA ̲ID : INTEGER;
D ̲COUNT : INTEGER;
FILE ̲POS : LONG;
DATA : ARRAY(1..80) OF CHAR;
C ̲COUNT: refers to no of significant characters
in CMD ̲NAME
DATA ̲ID ̲: 0, if all parameters in this rec.
1, if reference to a data record
D ̲COUNT: no of used characters in field DATA.
FILE ̲POS: used only when referring to data records
in data file.
Points to first data record to this
command.
label ̲rec:
label name
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲
0̲5̲ ̲L̲A̲B̲E̲L̲ ̲ ̲ ̲ ̲ ̲ ̲0̲ ̲4̲ ̲ ̲-̲ ̲ ̲X̲X̲X̲X̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲
end ̲rec:
label name
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
0̲3̲ ̲E̲N̲D̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲0̲ ̲4̲ ̲ ̲-̲ ̲ ̲X̲X̲X̲X̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
repeat ̲rec:
label name
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
0̲6̲ ̲R̲E̲P̲E̲A̲T̲ ̲ ̲ ̲ ̲ ̲0̲ ̲6̲ ̲ ̲-̲ ̲ ̲X̲X̲X̲X̲ ̲Y̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
no ̲of ̲repeats:integer
time ̲rec:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
̲4̲ ̲T̲I̲M̲E̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲0̲ ̲6̲ ̲ ̲-̲ ̲h̲h̲ ̲m̲m̲ ̲s̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
HOUR,MINUTE,SECOND:INTEGER
delay ̲rec:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
̲5̲ ̲D̲E̲L̲A̲Y̲ ̲ ̲ ̲ ̲ ̲ ̲0̲ ̲2̲ ̲ ̲-̲ ̲ ̲ ̲ ̲d̲d̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
delay:integer;
delay ̲factor ̲rec:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
1̲1̲ ̲D̲E̲L̲A̲Y̲F̲A̲C̲T̲O̲R̲ ̲0̲ ̲2̲ ̲-̲ ̲ ̲f̲f̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
delay factor:INTEGER;
fk ̲rec:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
̲2̲ ̲F̲K̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲0̲ ̲X̲ ̲ ̲-̲ ̲ ̲Y̲Y̲.̲.̲.̲.̲Y̲Y̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
functionkey ̲name:array(1..26)char.
password ̲rec:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
̲8̲ ̲P̲A̲S̲S̲W̲O̲R̲D̲ ̲ ̲ ̲0̲ ̲1̲2̲ ̲-̲ ̲X̲.̲.̲.̲.̲.̲.̲X̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
id ̲comma ̲passw:array(1..12)of char.
command ̲rec:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
̲7̲ ̲C̲O̲M̲M̲A̲N̲D̲ ̲ ̲ ̲ ̲0̲ ̲4̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
command ̲name:array(1..4)ofchar.
ex. SION
message ̲rec:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲
̲7̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲ ̲ ̲ ̲ ̲ ̲0̲ ̲X̲ ̲-̲ ̲ ̲t̲e̲x̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲
message ̲text:array(1..25)of char.
queue ̲rec:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
̲6̲ ̲Q̲U̲E̲U̲E̲S̲ ̲ ̲ ̲ ̲ ̲0̲ ̲5̲ ̲ ̲-̲ ̲ ̲X̲X̲X̲X̲ ̲Y̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
QUEUE ̲ID:array(1..4)of char;(RELS/RECV)
QUEUE ̲ACT: char (E/O)
stop ̲rec:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
̲4̲ ̲S̲T̲O̲P̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲0̲ ̲X̲ ̲ ̲-̲ ̲ ̲t̲e̲x̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
stop ̲message:array(1..25)of char.
terminate ̲rec:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
̲9̲ ̲T̲E̲R̲M̲I̲N̲A̲T̲E̲ ̲ ̲0̲ ̲4̲ ̲ ̲-̲ ̲ ̲t̲e̲x̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
term ̲message:array(1..25)ofchar.
data ̲rec (data in command ̲rec type)::
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
̲4̲ ̲D̲A̲T̲A̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲0̲ ̲X̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
field ̲rec:
split : integer;
line : integer;
column : integer;
data ̲lgth : integer;
data ̲text : array(1..80)
of char;
field ̲sep : char; (FS)
data ̲rec (data in DATA ̲file):
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
CMD ̲FILE ̲4̲ ̲D̲A̲T̲A̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲ ̲ ̲-̲ ̲ ̲P̲o̲i̲n̲t̲ ̲ ̲ ̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
DATA ̲FILE 2̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
fs : char; field ̲sep.
no : INTEGER; id ̲number;
data ̲id : INTEGER; always #22
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
field ̲1 ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
field ̲2 ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
field ̲n ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
field ̲rec as described above
verify ̲rec (in CMD ̲FILE):
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
\̲6̲ ̲V̲E̲R̲I̲F̲Y̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲0̲ ̲X̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
field ̲rec's as described
with data ̲rec.
Verify ̲rec (in DATA ̲FILE)
As described for data ̲rec.
4.2.9 L̲T̲U̲X̲ ̲T̲r̲a̲n̲s̲p̲a̲r̲e̲n̲t̲ ̲F̲i̲r̲m̲w̲a̲r̲e̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.9.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 LTUX ̲TSP supports the interface between two CAMPS
host computers via V24 asynchronous lines. It is supported
in the following ways:
o ASCII character transfer
o 2400 bps input/output speed
o Optional usage of V24 lines 105/106 and 108.2/107
o Optional flow control
o Optional usage of even/odd/none parity
o 8 bit/char + parity
o 1 - l 1/2 - 2 stop bits
Each LTUX ̲TSP can support different numbers of lines
(max.4 lines).
The DIL switch S2 decides the mode to run the program.
If CAMPS side then the switch shall be CLOSED. If Test
Drive side then OPEN.
4.2.9.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The following modules are defined:
INILSL: Initializes data structures such as queue
and buffer headers. Initializes scheduling
system.
PROCESS: Main routine activated by scheduling system
(one special section defined per channel).
Each section activates the subroutine needed
for service of actual channel.
LDUSCH: Main routine activated by scheduling system
(one special section defined per channel).
Each section activates the LDUDEMUX and
buffer release module of actual channel.
LDUREL: Buffer release module. Returns empty buffer
to queue indicated in buffer header byte
0 and 1.
LDUDEM: Reads LDU - buffer from TDX-I/F queue,
specified subdevice. The LDU's are verified
with respect to LDU-type, command codes
or data content. Data LDU's are delivered
in a special queue, command LDU's in an
other.
CMDINT: Reads command LDU's from the LDUDEM module.
The commands are verified and executed.
In most cases a completion code is returned.
The module generates asynchronous status
reports and transmission/reception status
reports too.
LINKPRO: This is the "master" module controlling
the input and output of data. The control
is based on V24-line state and commands
received by CMDINT.
OUTBHAND: Controls the transmission of data packets.
Whenever a LDU is finished a "transmission
status report" request is flagged to the
module CMDINT.
INBHAND: Controls the transport of LDU's from device
to CR80. The module will wait for device
ready and input request before releasing
any buffer for transmission on the TDX-system.
RXSYNT: Data from the V24 line are packed in buffers
as they are sent from opposite side. Data
are sent to the host exactly as received
from the 24 line (no packing in IOC records).
INTERRUPT: Interrupt routines used by serial interface
(SIO). Following interruptions are serviced:
TX-buffer empty, RX-character available,
external status interruption and special
receiver condition.
V24DRV: General subroutines used for initialization
and operation of serial interfaces (SIO's).
KERNEL: An assembly of subroutines used by one
or more of the other modules.
An overview of the firmware structure and the data
flow is shown in fig. 4.2.9.3-1. The figure shows one
channel, up to 4 channels may be used in each LTUX-TSP.
The figure does not show the scheduling system nor
the initialization modules.
4.2.9.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲ ̲W̲i̲t̲h̲i̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲
For each channel used a number of queues are defined.
INFTQ: Data buffers ready for transmission. IOC-record
headers are sent unchanged and transmitted
as data.
Enqueing module: LDUDEM
Dequeing module: OUTBHAND
Initial no. of elements: 0
INTCQ: Command buffers with commands from the
CR80 or locally generated commands. The
CR80 commands are validated with respect
to command code and buffer size.
Enqueing module: LDUDEM
Dequeing module: CMDINT
Initial no. of elements: 0
INETQ: Empty packet buffers for outbound data.
Enqueing module: OUTBHAND
Dequeing module: LDUDEM
Initial no. of elements: 2
INFRQ: Data buffer with inbound data ready for
delivery to the CR80.
Enqueing module: RXSYNT
Dequeing module: INBHAND
Initial no. of elements: 0
INERQ: This queue is not used in LTUX-TSP
INWRQ: Empty pocket buffers for inbound data.
Enqueing module: LDUREL, INBHAND
Dequeing module: RXSYNT
Initial no. of elements: 3
INFIQ: This queue is not used in LTUX-TSP
INEIQ: Empty buffers for asynchronous reports
for the CR80.
Enqueing module: LDUREL
Dequeing module: CMDINT
Initial no. of elements: 3
INTRQ: "Output request" buffers received from
LDUDEM by CMDINT. The buffers are for transmission
to complete, and are used for the generation
of transmission status report.
Enqueing module: CMDINT
Dequeing module: CMDINT
Initial no. of elements: 0
INWCQ: Command buffer received from LDUDEM by
CMDINT. The buffers are waiting for the
completion of actual command (open/close
protocol), and are used for the generation
of completion code.
Enqueing module: CMDINT
Dequeing module: CMDINT
Initial no. of elements: 0
Fig. 4.2.9.3-1
4.2.9.4 M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
4.2.9.4.1 M̲o̲d̲u̲l̲e̲ ̲I̲N̲I̲T̲S̲P̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
4.2.9.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̲
This module cleares all RAM and initializes buffer-
and queue-headers. RAM areas are reserved for control
tables (TSPCTAB 1-4). Process scheduling is initialized.
The resulting schedule list is:
LSJAK 1 (LDUDEM, LDUREL)
SCANIN (TDX-service)
SCANOUT (TDX-service) JACK 1 service
PROCESS 1 (CMDINT, OUTBHAND,
LINKPRO, RXSYNT,
INBHAND)
SCANIN
SCANOUT
LSJAK 2
SCANIN
SCANOUT JACK 2 service
PROCESS2
SCANIN
SCANOUT
LSJAK3
SCANIN
SCANOUT
PROCESS3 JACK 3 service
SCANIN
SCANOUT
LSJAK4
SCANIN
SCANOUT
PROCESS4 JACK 4 service
SCANIN
SCANOUT
The process INITSP is passivated, when init is finished.
V24-driver tables are initialized
4.2.9.4.1.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Module is activated as process no. 4 and must be situated
a PROM location 6000H
4.2.9.4.1.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
N.A.
4.2.9.4.1.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Actual buffer and queue layout are determined by the
tables BETA 1 (JACK 1 - JACK 4), and table BRAM. Resulting
buffer layout per JACK are:
QUEUE NO. OF SIZE OFF-SET
BUFFERS
TDX-outbound
empty buffer 3 128 0
INETQ 2 131 3
INEIQ 3 16 0
INWRQ 3 128 0
4.2.9.4.1.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
I̲n̲i̲t̲i̲a̲l̲i̲z̲e̲ ̲T̲S̲P̲
Clear all RAM
Create application processes
Passivate init processes
Evaluate buffers
Initialize V24-driver
Schedule
FIGURE 4.2.9.4.1.5-1
4.2.9.4.2 M̲o̲d̲u̲l̲e̲ ̲L̲D̲U̲S̲C̲H̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.9.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̲
This module defines 4 processes (one for each jack)
to serve the communication to/from the LTUX system
firmware. A jack table (one for each process) is initialized.
4.2.9.4.2.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The module is activated by the scheduler and call the
modules: LDUREL and LDUDEM.
4.2.9.4.2.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
The module consists of 4 sections, each serving one
JACK. Each section contains a main program (LSJA10,
LSJA20, LSJA30, LSJA40) and a subroutine (LSINI1, LSINI2,
LSINI3, LSINI4) and a common subroutine (LSQINI).
4.2.9.4.2.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
A JACK table is defined for each JACK. The offset to
the elements in the table is showing in section 4.2.9.5.
4.2.9.4.2.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
When first time activated the module initializes the
JACK table. In normal running the release buffer routine
(LDUREL) is called and the LDU demultiplexing routine.
Then the process is scheduled out.
4.2.9.4.3 M̲o̲d̲u̲l̲e̲ ̲L̲D̲U̲R̲E̲L̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.9.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 releases empty buffers from the TDX bus
to the empty queues.
4.2.9.4.3.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The module dequeued buffers from TDX Inbound Empty
Queue. The buffers are enqueued in Waiting Receiver
Queue (INWRQ), Empty Interrupt Queue (INEIQ) and TDX
Outbound Empty Queue.
4.2.9.4.3.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
The module contains only a little main program.
4.2.9.4.3.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The following queues are used:
TDX Inbound Empty Queue
TDX Outbound Empty Queue
Waiting Receiver Queue (INWRQ)
Empty Interrupt Queue (INEIQ)
4.2.9.4.3.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The TDX Inbound Empty Queue is polled. If the buffer
available then the address of return queue is checked.
If the MSB address is zero then the buffer is a TDX
buffer and will be sent to TDX Outbound Empty Queue.
Else the buffer will be sent to either Empty Interrupt
Queue or Waiting Receiver Queue.
4.2.9.4.4 M̲o̲d̲u̲l̲e̲ ̲L̲D̲U̲D̲E̲M̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.9.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̲
Buffers from TDX Outgoing Package Queue are dequeued.
D̲a̲t̲a̲ ̲B̲u̲f̲f̲e̲r̲s̲ are copied to another buffer and the new
buffer is enqueued in Full Transmitter Queue (INFTQ).
If the buffer is Start of LDU or Entire LDU then the
original buffer is sent to the Control Queue (INTCQ)
as an output request. Else the original buffer is released
to TDX Outbound Empty Queue. The sequence of the buffer
shall be correct else an error report is sent to the
host.
C̲o̲m̲m̲a̲n̲d̲ ̲B̲u̲f̲f̲e̲r̲s̲ are sent directly to the Control Queue
(INTCQ). The command "Input Request" is handled in
two ways depending on whether it is the CAMPS side
or the Test Driver side. If CAMPS side then the "Input
Request" is sent to the Full Transmitter Queue too.
4.2.9.4.4.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The module receives full buffers from TDX Outgoing
Package Queue. Empty buffers are fetched from Empty
Transmitter Queue (INETQ). Full buffers are delivered
to Full Transmitter Queue (INFTQ) or Control Queue
(INTCQ).
4.2.9.4.4.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
The module contains a main program, state/event table,
some actions and coroutines. Below the header of the
subroutine with the call parameters and a short description
are listed.
LIST OF HEADER
4.2.9.4.4.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The JACK table is used. The layout listed in 4.2.9.5
FIGURE 4.2.9.4.4.3-1
FIGURE 4.2.9.4.4.3-2
FIGURE 4.2.9.4.4.3-3
The transmission buffer is formatted with an offset
of 6 bytes. The first two bytes use the module OUTBHAND.
The four next are transmitted at the V24 line to indicate
start of buffer.
The buffer format is shown below.
FIGURE 4.2.9.4.4.4-1
4.2.9.4.4.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
LDU Demultiplexing ()()
Less than min.no. of buf.in INETEQ ?
Dequeue TDX package queue
Buffer not available ?
Completion code not zero ? Async.report: TDX error
Buffer to control queue
Bytecount EQ zero ? Release buffer to TDX
outbound empty queue
Command buffer ? Check command and format and get event
Get event
Calculate event/state
Case LDUDEM action of
LDUA00 ? Dummy
LDUA10 ? Release buffer to TDX
LDUA20 ? Buffer to TX queue SOL/ENL
LDUA30 ? Buffer to TX queue
LDUA40 ? Command to LTUX
LDUA50 ? Input request
LDUA60 ? Illegal command
LDUA70 ? Command out of sequence
End LDUDEM action case.
Return
FIGURE 4.2.9.4.4.5-1
4.2.9.4.5 M̲o̲d̲u̲l̲e̲ ̲P̲R̲O̲C̲E̲S̲S̲E̲S̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.9.4.5.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module defines 4 processes, PROCESS1-4, each serving
the corresponding jack no.
When activated the first time the process performs
the final initialization of control table and V24 driver.
4.2.9.4.5.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
N/A
4.2.9.4.5.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Module consist of 4 sections, each serving one JACK.
The sections are scheduled individually.
4.2.9.4.5.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
N.A.
4.2.9.4.5.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
An overall flowgram is shown (fig. 4.2.9.4.5.5-1)
Processes
Init control table of JACK1
Loop
Call relevant modules
Schedule
End loop
Init control table of JACK2
Loop
Call relevant modules
Schedule
End loop
Init control table of JACK3
Loop
Call relevant module
Schedule
End loop
Init control table of JACK4
Loop
Call relevant module
Schedule
End loop
FIGURE 4.2.9.4.5.5-1
4.2.9.4.6 M̲o̲d̲u̲l̲e̲ ̲C̲M̲D̲I̲N̲T̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.9.4.6.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 command interpreter module receives commands from
the LDU demultiplex modules. Commands may be init commands,
input request or error reports. Another function of
the command interpreter is the generation of command
responses, TX and RX completion codes and asynchronous
error reports.
4.2.9.4.6.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Command buffers are received on queue INTCQ. Empty
buffer for reports etc. are fetched from INEIQ. Reports
etc. are delivered for the TDX-bus for transmission
(JACK1 uses subdevice 2, JACK2 uses subdevice 3 etc.).
Two control bytes, CMDCONT1 and CMDCONT2, are used
to indicate reports to generate. Error codes are returned
in other 7 bytes, for details refer section 4.2.9.5:
Common subpackage data.
4.2.9.4.6.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Module contain a sequential code area and a section
with the fixed part of the responses/reports to be
used.
4.2.9.4.6.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The data formats used corresponds to the formats specified
in section 4.1.4 Common package data.
4.2.9.4.6.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
C̲o̲m̲m̲a̲n̲d̲ ̲i̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲
Command queue empty?
Get command/error report
Internale report? I̲n̲t̲e̲r̲n̲a̲l̲e̲ figure 4.2.9.9.5-2
Case of command code
Input request? Signal to INBHAND
Cancel inp. req.? Command not allowed
Report status? L̲i̲n̲e̲ ̲c̲o̲m̲m̲a̲n̲d̲s̲ figure
4.2.9.9.5-3
Open channel? Signal to LINKPRO
Close channel? Signal to LINKPRO
End command case
Get control bytes
Test flags
Generate reports accordingly
End
FIGURE 4.2.9.4.6.5-1
I̲n̲t̲e̲r̲n̲a̲l̲e̲
ASYNC status report?
Completion code NE 0? Send buffer to host
Queue buffer to TX-status
FIGURE 4.2.9.4.6.5-2
L̲i̲n̲e̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
Case of subcommand
Enable? Verify enable command
Init table accordingly
Signal to LINKPRO
Open Protocol? Signal to LINKPRO
Close Protocol? Signal to LINKPRO
Statistic? Generate statistic report
Status ? Generate status report
Device status? Generate device status
report
End subcommand case
FIGURE 4.2.9.4.6.5-3
4.2.9.4.7 M̲o̲d̲u̲l̲e̲ ̲L̲I̲N̲K̲P̲R̲O̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.9.4.7.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module is the "master" module in the LTUX-TSP.
It controls all data transfer based on the state of
the V24-lines and based on the commands received from
the command interpreter.
4.2.9.4.7.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Thru the control table the module receives the necessary
information from the other modules. The module receives
no data packets from any module.
4.2.9.4.7.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Module consists of a program part, a state/event table,
a number of actions and some special subroutines.
4.2.9.4.7.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The module refers to a number of fields in the control
table, the most important being the control byte (LINKCONT)
and the timer fields. For more details refer to section
4.2.9.5 Common subpackages data.
4.2.9.4.7.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
L̲i̲n̲k̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
Update all active timers
Get V24 state of JACK
Update V24-event-field
Get link control byte
No flags set? Event based on V24 state
Determine event
Determine new state
Determine action
A̲c̲t̲i̲o̲n̲s̲ figure 4.2.9.4.4.5-2
End
FIGURE 4.2.9.4.7.5-1
A̲c̲t̲i̲o̲n̲s̲
Case of action
LINKA000? no action
LINKA010? open out of sequence
LINKA020: close out of sequence
LINKA030: start open protocol
LINKA040: complete open protocol
LINKA050: open failed
LINKA060: open command overrided
LINKA070: drop V24-line 106 and 107
LINKA080: drop V24-line 106
LINKA090: drop V24-line 107
LINKA100: device failure due to drop 106 and
107
LINKA110: clean-up for restart
LINKA120: device failure due to close protocol
LINKA130: device failure due to paper out
LINKA140: recover after device failure
LINKA150: device failure due to drop 106
LINKA160: device failure due to drop 107
LINKA170: device failure due to unexpected action
LINKA180: V24-OK but paper out
LINKA190: error restart (master clear LTUX)
LINKA200: 106, low, check for timeout
LINKA210: 107 low, check for timeout
LINKA220: 106 and 107 low, check for timeout
LINKA230: waiting for V24-OK, check open timer
End action case
FIGURE 4.2.9.4.7.5-2
C̲l̲o̲s̲e̲ ̲d̲o̲w̲n̲ ̲a̲f̲t̲e̲r̲ ̲d̲e̲v̲i̲c̲e̲ ̲e̲r̲r̲o̲r̲
Disable transmitter
Disable receiver
Drain receiver registers
Close V24 line
Update state of V24
Stop used timer
Signal dev. fail for OUTBHAND
Signal dec. fail to INBHAND
Return
FIGURE 4.2.9.4.7.5-3
V̲2̲4̲-̲l̲i̲n̲e̲ ̲1̲0̲6̲ ̲t̲i̲m̲e̲o̲u̲t̲ ̲o̲r̲ ̲1̲0̲7̲ ̲t̲i̲m̲e̲o̲u̲t̲
Get state of timer
No timeout?
Signal timeout to LINKPRO
Reset timeout
Return
FIGURE 4.2.9.4.7.5-4
Fig. 4.2.9.4.7.5-5…01…Determination of V24-event
Fig. 4.2.9.4.7.5-6…01…LINKPRO state/action tables
4.2.9.4.8 M̲o̲d̲u̲l̲e̲ ̲O̲U̲T̲B̲H̲A̲N̲D̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.9.4.8.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module controls the transmission of data. When
a LDU is finished (or transmission repeated) a transmission
status report is generated (completion forwarded to
CMDINT and corresponding flag set).
4.2.9.4.8.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Information status about changes in the link protocol
(LINKPRO) are received in the control table by OUTBCONT.
Full data buffers are received in queue INFTQ.
Buffers are delivered for transmission by interrrupt
routine thru the control table. The pointer and byte
count areas (TXBYTES, TXNEXTL, TXNEXTM) are loaded
with the current values. Whenever a buffer has to be
cancelled it is returned as empty in the queue INETQ.
4.2.9.4.8.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Module contains 4 parts: Event determination, state/action-tables,
action programs and special subroutines. 4 subroutines
are defined, ref. overleaf.
4.2.9.4.8.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The module uses the common control table. Most important
is the OUTBCONT byte in which events are received from
other modules. The transmission control section storing
buffer links element, current position and bytes lift
is important too. For details refer 4.2.9.5.
FIGURE 4.2.9.4.8.3-1
4.2.9.4.8.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The module is state/event controlled with the first
part used to determine actual event.
Outbound Handler
No flags set ? Transmission active
?
Buffer not ready ?
Get buffer type
Buffer type EQ event
Control entire LDU
Not cancel this LDU
Event EQ cancel
Determine new state
Determine action
Outbound Action
Return
FIGURE 4.2.9.4.8.5-1
O̲u̲t̲b̲o̲u̲n̲d̲ ̲a̲c̲t̲i̲o̲n̲s̲
case action of
OUTBA000? no action
OUTBA010? start TX of buffer
OUTBA020? cancel buffer
OUTBA030? generate TX-status = OK
OUTBA040? not used (spare)
OUTBA050? cancel buffer, gen. device error
OUTBA060? cancel buffer, gen device status errror
OUTBA070? release buffer, gen. device error
OUTBA080? release buffer, gen. device
status error
OUTBA090? release buffer due to cancel cmd
OUTBA100? cancel SOL/EOL due to cancel cmd
OUTBA110? Unexpected start of LDU
OUTBA120? Spare
OUTBA130? Spare
OUTBA140? Spare
OUTBA150? Error restart (master clear LTUX)
OUTBA160? Start TX of buffer, SOL or EOL
end of action cases.
FIGURE 4.2.9.4.8.5-2
Fig. 4.2.9.4.8.5-3
OUTBHAND state and action tables
4.2.9.4.9 M̲o̲d̲u̲l̲e̲ ̲I̲N̲B̲H̲A̲N̲D̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.9.4.9.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Controls the transport of LDU's from device to CR80.
The module will wait for device ready and input request
before releasing any data buffer for transmission on
the TDX-system. Control buffers can be delivered to
the TDX system without an input request.
4.2.9.4.9.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
External events are signalled to the module in the
control table, byte INBCONT. The current LDU no. to
insert in case of LDU-TYPE = SOL/EOL is read from control
table too (byte RLDU ̲NO). For details ref. section
4.2.9.5.
Bufer ready to transmission on the TDX-bus are received
in queue INFRQ. When a buffer is released for transmission
on TDX-bus, subdevice no. (1 + JACK no.) is used.
When a buffer is descarded it is inserted as empty
in the queue INWRQ.
4.2.9.4.9.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
As many of the other modules this contains 4 parts:
event determination, state/action table, action programs
and special subroutines. Only one subroutine is defined;
ref. below.
FIGURE 4.2.9.4.9.3-1
4.2.9.4.9.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲s̲
The module uses the common control table. The INBCONT
byte is the most important part (as in any other module).
For details ref. section 4.2.9.5.
4.2.9.4.9.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The module is state/event controlled with the first
part used to determine actual event.
INBHAND
Get control byte
No flags set? Receiver timeout? Full receiver
queue not empty?
Event EQ 8
Dequeue full receiver queue
Buffer not available?
Event EQ LDU-type
Determine new state
Determine action
I̲n̲b̲o̲u̲n̲d̲ ̲a̲c̲t̲i̲o̲n̲s̲
Return
FIGURE 4.2.9.4.9.5-1
I̲n̲b̲o̲u̲n̲d̲ ̲a̲c̲t̲i̲o̲n̲
Case action of
INBA000: No action
INBA010: Discard buffer
INBA020: Transmit buffer as SOL/EOL*
INBA030: Transmit buffer as POL/LOL*
INBA040: Clean-up after device error
INBA050: Clean-up after dev. status error
INBA060: SOTF-interruption*
INBA070: Reset when device ready
INBA080: Generate reciver timeout report
INBA090: Cancel input request
End of action case
* A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲:
LDU: Logical data unit
SOL: Start of LDU
POL: Part of LDU
LOL: Last of LDU
ENL: Entire LDU
FIGURE 4.2.9.4.9.5-2
4.2.9.4.10 M̲o̲d̲u̲l̲e̲ ̲R̲X̲S̲Y̲N̲T̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.9.4.10.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Handles the transport of characters from RXFIFO to
packed in buffers. Fins start of the buffer and the
length by the sequence:"GS", "GS", "*", "bytecounter".
Report error if the length of the buffer is incorrect,
if a new buffer is started before current not finished,
or if buffer not finished.
4.2.9.4.10.3 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
External events are signalled to the module in the
control table, byte RXSYCONT.
Characters are read from Receiver F/FO (RXFIFO) and
buffers are delivered to Full Receiver Queue (INFRQ).
Empty buffers are fetched from Waiting Receiver Queue
(INWRQ). There also using a Syntax FIFO (SYFIFO) to
temporary store of start of buffer characters.
4.2.9.4.10.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
The module contains 4 parts: Event termination, state/action
tables, action programs and subroutines. Overleaf the
header of subroutines is shown.
FIGURE 4.2.9.4.10.3-1
4.2.9.4.10.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
In the control table there is a special section to
the Receiver Syntax Analysis, ref. 4.2.9.5.
The format of the data from the V24 line is described
in section 4.2.9.4.4.4.
4.2.9.4.10.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
Receiver Syntax ()()
Not min. no. of buf. in INWRQ ?
Receiver Loop:
Time-out ? Event 4
Buffer overrun ? Event 3
Buffer finish ? Event 5
Get char. from RXFIFO
RXFIFO empty ? Exit loop
Char. EQ GS ? Event 0
Char. EQ * ? Event 1
Event 2
Calculate new state
Get action
Case of Receiver Actions:
RXACOO ? Dummy
RXAC10 ? Bytecounter
RXAC20 ? Character to Buffer
RXAC30 ? Character to Syntax FIFO
RXAC40 ? Start of new buffer in data
RXAC50 ? Not start of buffer
RXAC60 ? Buffer overrun
RXAC70 ? Time-out
RXAC80 ? Buffer finish
RXAC90 ? End buffer
RXERR ? Error Action
End of Receiver Actions Case
End Receiver Loop
Return.
FIGURE 4.2.9.4.10.5-1
FIGURE 4.2.9.4.10.5-2
4.2.4.3.4.11 M̲o̲d̲u̲l̲e̲ ̲I̲N̲T̲E̲R̲R̲U̲P̲T̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.4.3.4.11.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This is the low level communication module. The subroutines
defined are all interrupt activated (except for TXSTOP)
and deal with character I/O and SIO control.
4.2.4.3.4.11.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The subroutines defined are called from the corresponding
interrupt routine in the V24DRV module. The routines
uses the general control table, ref. section 4.2.4.3.5.
4.2.4.3.4.11.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Module contains 5 subroutines, ref. section module
design.
4.2.4.3.4.11.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The Output and Input section in the control table are
used by the interrupt routines.
4.2.4.3.4.11.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The subroutines are shown on the following pages.
Transmitter interrupt ()()
Next TX-byte valid ? More bytes to send
?
Release buffer to INETQ
Clear buf.info. in
cont.table
Indicate buffer finish
Stop transmitter ()()
Update pointers
Send character
Return
FIGURE 4.2.9.4.11.5-1
Receiver char. interrupt ()()
Read character
Parity error? Load replace character
Write char. to RX-FIFO
RX-FIFO full? Indicate error
FIFO exceed flow boundary ? - Activate flowcontrol
Restart receiver timer Stop receiver timer
Return
FIGURE 4.2.9.4.11.5-2
Special Receiver Conditions ()()
Read Error Status ()(status byte)
Framing error? Indicate RX char. error
Send error report
Increment no. of framing error
Receiver overrun? Indicate receiver error
Send error report
Increment no. of RX overrun
Parity error? Indicate RX char. error
Increment no. of parity error
Return
FIGURE 4.2.9.4.11.5-3
Externale Status Interrupt (status byte)()
Break/abort? Indicate receiver error
Send error report
Return
FIGURE 4.2.9.4.11.5-4
Stop Transmitter ()()
Reset TX interrupt pending
Indicate transmission stopped
Return
FIGURE 4.2.9.4.11.5-5
4.2.9.4.12 M̲o̲d̲u̲l̲e̲ ̲V̲2̲4̲ ̲D̲r̲i̲v̲e̲r̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.9.4.12.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 V24 driver is a collection of utilities to make
the use of the SIO easy. A number of subroutines is
defined which communicate directly with the SIO in
accordance with the call parameters.
4.2.9.4.12.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Refer to Module Components 4.2.9.4.12.3.
4.2.9.4.12.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
The following subroutines are defined:
VDINIT: Initialize V24 driver
VCINIT: Initialize V24 channel
SETSIO: Setup S10 channel
ESENAB: Enable external status interrupt
ESDIAB: Disable external status interrupt
TXE: Transmitter enable
TXD: Transmitter disable
RXE: Receiver enable
RXD: Receiver disable
RDRAIN: Receiver drain
SBREAK: Send break
TBREAK: Terminate break
OUCHAR: Output character
INCHAR: Input character
RERSTA: Read error status
GEXSTA: Get external status
VOPCON: V24 output control
SETCTC: Set CTC channel
T1ESER: TX buffer empty interrupt service routine-
jack 1 (one each jack)
R1ASER: RX char. available interrupt service routine
- jack 1 (one each jack)
R1ESER: RX error interrupt service routine - jack
1 (one each jack)
E1SSER: External status change interrupt service
routine - jack 1 (one each jack)
RETINT: Return from interrupt.
If details wanted then see source code.
4.2.9.4.12.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The module uses some tables special to the SIO. They
are shown overleaf.
FIGURE 4.2.9.4.12.4-1
FIGURE 4.2.9.4.12.4-2
4.2.9.4.12.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The module is a SIO service module and contains only
subroutines and tables. Four routines per jack are
activated by interrupt from the SIO. These routines
save the actual used registers. The address of the
control table is saved too, and the address of the
control table belonging to the jack is loaded. Then
one of the routines in the module INTERRUPT is called.
When returning from interrupt the original registers
and control tables are restored.
The other routines are called from other modules to
handle the SIO.
4.2.9.4.12.6 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
To ensure that the modules may be used reentrant all
variables are assembled in a control table . The variables
are addressed by use of the Z80 index register IX plus
on offset. The variable is defined by the value of
this offset. In the actual design 4 control tables
and 4 jack tables are defined, two tables per JACK.
The tables are completely independent.
A number of constants are used which are specific to
the LTUX-OCR subpackage. Their names, values and usage
are shown in OCR ̲NAMES.
FIGURES 4.2.9.5-1 to 4.2.9.5-7
4.2.9.4.12.7 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̲
The subroutines are assembled in the module KERNEL.
On the following pages they are described by their
subroutine headers. The following subroutines are defined:
GENRESPO
GENASYNC
RANGE
SWTIM
LOOKUP
INIT QUARE
CASE
DISBUF
FIFPUT
FIGURES 4.2.9.6-1 to 4.2.9.6-3
4.2.9.7 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Refer to Interface 4.1.7.2 and LTUX-S V24 Interfaces
CMS/TCN/031
4.3 M̲E̲M̲O̲R̲Y̲ ̲L̲A̲Y̲O̲U̲T̲
Refer to TDP ̲VDU link list
4.3.9 M̲e̲m̲o̲r̲y̲ ̲L̲a̲y̲o̲u̲t̲ ̲L̲T̲U̲X̲ ̲T̲S̲P̲
FIGURE 4.3.9-1
