top - download
⟦a2d3b26e9⟧ Wang Wps File
Length: 53848 (0xd258)
Types: Wang Wps File
Notes: Spelunked
Names: »~ORPHAN64.00«
Derivation
└─⟦060f447e1⟧ Bits:30006194 8" Wang WCS floppy, CR 0460A
└─ ⟦this⟧ »~ORPHAN64.00«
WangText
>
=…0a…=…00…=…02…=
=…07…<…0f…<…06…;…0a…;…0b…;…0f…; ;…07…:…0d…:…02…9…08…9…09…9…0f…9
8…0a…8…0f…8…05…7…0b…7…00…7…06…6…0b…6…01…6 5…09…5…0d…5…02…4…08…4…0d…4…02…3…08…3…0d…3
2…08…2…0c…2…01…2…06…1…0a…1…00…1 0…08…0…0c…0…86…1
…02…
…02…
…02…
…02…CPS/SDS/039
…02…840601…02……02…
USER VDU
DETAILED
DESIGN
SPECIFICATION…02…ISSUE
1…02…CAMPS
4.2.3
4.2.3.1 unctional Specification ...........
4.2.3.1.1 Control of main flow (VDIA main
loop) ..........................
4.2.3.1.2 Interpretation of format control
"programmes" ...................
.2.3.1.3 Input from/output to VDU (VDU
access method) .................
4.2.3.1.4 Read from/write to CIF (CIF
access method) .................
4.2.3.1.5 Read from/write to memory
(memoryaccess method) .........
4.2.3.1.6 Read/write from sequences
(sequence access method) .......
4.2.3.1.7 Validation and conversion. .....
4.2.3.1.8 Error handling (Errl.) .........
4.2.3.1.9 Hadling of dynamic memory
(memory management) ............
4.2.3.2 Software Structure .................
4.2.3.2.1 Main Components of VDIA ........
4.2.3.2.2 VDU Format and Associated Contro
4.2.3..3 Format Model and VDU Field Type
4.2.3.2.4 Format Control Programme (FCP) .
4.2.3.2.5 VDIA Data Layout ...............
4.2.3.3 Data Flow, Control Structure .......
4.2.3.7 Subpackage Interface ..............
4.2.3.7.1 UFCO VDIA UFCO INTERFACE .......
4.2.3.7.2 VDIA USPR VDIA Interface .......
4.2.3.4.1 VDIA MAIN ......................
4.2.3.4.1.1 VDIA Main Loop Specification
4.2.3.4.1.1.1 Functiona Specification
4.2.3.4.1.1.3 Module Components ......
4.2.3.4.1.1.2 Data Description .......
4.2.3.4.1.2 Stack Error Specification ..
4.2.3.4.1.2.1 Functional Specification
4.2.3.4.1.2.2 Mdule Interface .......
4.2.3.4.1.2.3 Module components ......
4.2.3.4.1.3 Long Exit Specification ....
4.2.3.4.1.4 Wait Vdu I O Specification .
4.2.3.4.2 Format Program Interpreter .....
4.2..4.2.1 Format Control Programme
Interpreter Main spec. .....
4.2.3.4.2.1.1 Functional Specification
4.2.3.4.2.1.2 Module Interface .......
4.2.3.4.2.1.3 Module Components ......
4.2..4.2.1.4 Data Description .......
4.2.3.4.2.1.5 Module Design ..........
4.2.3.4.2.2 Format Control Programme
Interpreter Input Spec. ....
4.2.3.4.2.2.1 Functional Specification
42.3.4.2.2.2 Module Interface .......
4.2.3.4.2.2.3 Module Components ......
4.2.3.4.2.2.4 Data Description .......
4.2.3.4.2.2.5 Module Design ..........
4.2.3.4.2.3 Format Control Programme
Interpreter Disp spec. .....
4.2.3.4.2.3.1 Functional Specification
(Module Design) ........
4.2.3.4.2.3.2 Module Interface .......
4.2.3.4.2.3.3 Module Components ......
4..3.4.2.3.4 Data Description .......
4.2.3.4.2.3.5 Module Design ..........
4.2.3.4.2.4 Format Control Programme
Contr Specification ........
4.2.3.4.2.4.1 Functional Specification
(Module Design) ........
4.2.3.4.2.4.2 Module Interface .......
4.2.3.4.2.4.3 Module Components ......
4.2.3.4.2.4.4 Data Description .......
4.2.3.4.2.4.5 Module Design ..........
4.2..4.2.5 Format Control Programme
Seq Specification ..........
4.2.3.4.2.5.1 Functional Specification
(Module Design) ........
4.2.3.4.2.5.2 Module Interface .......
4.2.3.4.2.5. Module Components ......
4.2.3.4.2.5.4 Data Description .......
4.2.3.4.2.5.5 Module Design ..........
4.2.3.4.2.6 Format Control Programme
M̲i̲s̲c̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ .........
4.2.3.4.2.6.1Functional Specification
4.2.3.4.2.6.2 Module Interface .......
4.2.3.4.2.6.3 Module components ......
4.2.3.4.2.6.4 Data Description .......
4.2.3.4.2.6.5 Module Design ..........
4.2.3.42.7 Format Control Programme Aux
Specification ..............
4.2.3.4.2.7.1 Functional Specification
4.2.3.4.2.7.2 Module Interface .......
4.2.3.4.3 VDU Access Method ..............
4..3.4.3.1 Vdu Access Method Main
Specification ..............
4.2.3.4.3.1.1 Functional Specification
4.2.3.4.3.1.2 Module interface .......
4.2.3.4.3.1.3 Module Components ......
4.2.34.3.1.4 Data Description .......
4.2.3.4.3.2 Vdu Access Method Model
Specification 4.2.3.4.3.2.1
Functional
Specification
...
4.2.3.4.3.2.2 Module Interface .......
4.2.3.4.3.2.3 Module Compoents ......
4.2.3.4.3.2.4 Data Description .......
4.2.3.4.3.3 Vdu Access Method Io
Specification ..............
4.2.3.4.3.3.1 Functional Specification
4.2.3.4.3.3.2 Module Interface ......
4.2.3.4.3.3.3 Module Components ......
4.2.3.4.3.3.4 Data Description .......
4.2.3.4.3.4 Vdu Access Method Errl
Specification ..............
4.2.3.4.3.4.1 Functional Specification
4.2.3.4.3.4.3 Module Components ......
4.2.3.4.3.4.4 Data Description .......
4.2.3.4.4 Cif Access Method ..............
4.2.3.4.4.1 Cif Access Method
Specification ..............
4.2.3.4.4.1.1 Functional Specification
4.2.3.4.4.1.2 Module Interface .......
4.2.3.4.4.1.3 Module Components ......
4.2.3.4.4.1.4 Data Description .......
4.2.3.4.5 Memory Access Method - Mem Ac.
4.2.3.4.5.1 Memory Access Method
Specification ..............
4.2.3.4.5.1.1 Functional Specification
4.2.3.4.5.1.2 Module Interface .......
4.2.3.4.5.1.3 Module Components ......
4.2.3.4.5.1.4 Data Description .......
4.2.3.4.6 Field Sequence Access Method
Seq Acc ........................
4.2.3.4.6.1 Sequence Access Method
Specification ..............
42.3.4.6.1.1 Functional Specification
4.2.3.4.6.1.4 Data Description .......
4.2.3.4.7 Memory Management (Mem-Man) ....
4.2.3.4.7.1 Memory Management
Specification ..............
4.2.3.47.1.1 Functional Specification
4.2.3.4.7.1.2 Module Interface .......
4.2.3.4.7.1.3 Module Components ......
4.2.3.4.7.1.4 Data Description .......
4.2.3.4.8.1 Common Modules .............
4.2.3.4.8.1.1 Functial Specification
Copy ...................
4.2.3.4.8.1.2. Module Interface ......
4.2.3.4.8.1.3 Module Components .....
4.2.3.4.8.1.4 Data Description .......
42.3.4.8.2.1 Functional Specification
Get Mhi ................
4.2.3.4.8.2.2 Module Interface .......
4.2.3.4.8.2.3 Module Components ......
4.2.3.4.8.2.4 Data Description .......
4..3.4.8.3.1 Functional Specification
Vdia Com ...............
4.2.3.4.8.3.2 Module Interface .......
…86…1 …02… …02… …02… …02…
4.2.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̲
To fulfil the task of VDIA, which is mainly to transform
data from internal format to the format presented on
the VDU and visa versa, the followig functions should
be implemented in the subpackage:
- control of main flow (VDIA main loop)
- interpretation of format control "programmes"
- input from/output to VDU (VDIA access method)
- Read from/write to CIF (CIF access method)
- Read fom/write to memory (memory access method)
- Read from/write to sequence (sequence access method)
- Validation and conversion (Display, Syntax and semantic)
- Error handling (Errl.)
- Handling of dynamic memory (memory management)
4.2.3.1.1 C̲n̲t̲r̲o̲l̲ ̲o̲f̲ ̲m̲a̲i̲n̲ ̲f̲l̲o̲w̲ ̲(̲V̲D̲I̲A̲ ̲m̲a̲i̲n̲ ̲l̲o̲o̲p̲)
VDIA main loop receives commands in the activation
semaphore and control the main flow of the execution
of the commands.
4.2.3.1.2 I̲n̲t̲e̲r̲p̲r̲e̲t̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲f̲o̲r̲m̲a̲t̲ ̲c̲o̲n̲t̲r̲o̲l̲ ̲"̲p̲r̲o̲g̲r̲a̲m̲m̲e̲s̲"
This module performs the exeution of the format control
programme connected to the format displayed on the
screen. Each format, which contains fields, has an
associated format control programme.
4.2.3.1.3 I̲n̲p̲u̲t̲ ̲f̲r̲o̲m̲/̲o̲u̲t̲p̲u̲t̲ ̲t̲o̲ ̲V̲D̲U̲ ̲(̲V̲D̲U̲ ̲a̲c̲c̲e̲s̲s̲ ̲m̲e̲t̲h̲o̲d̲)
Performs all input an output to the VDU. This module
is responsible for conversion between addressing on
the VDU (line, incornation and field number) and internal
adddressing (field type, field replica)
4.2.3.1.4 R̲e̲a̲d̲ ̲f̲r̲o̲m̲/̲w̲r̲i̲t̲e̲ ̲t̲o̲ ̲C̲I̲F̲ ̲(̲C̲I̲F̲ ̲a̲c̲c̲e̲s̲s̲ ̲m̲e̲t̲h̲o̲d̲)
The CIF ccess method performs read/write of data which
is/shall be stored in CHAMPS INTERNAL FORMAT (CIF).
4.2.3.1.5 R̲e̲a̲d̲ ̲f̲r̲o̲m̲/̲w̲r̲i̲t̲e̲ ̲t̲o̲ ̲m̲e̲m̲o̲r̲y̲ ̲(̲m̲e̲m̲o̲r̲y̲ ̲a̲c̲c̲e̲s̲s̲ ̲m̲e̲t̲h̲o̲d̲)
The memory access method accesses data in memory records.
4.2.3.1.6 R̲e̲a̲d̲/̲w̲r̲i̲t̲e̲ ̲f̲r̲o̲m̲ ̲s̲e̲q̲u̲e̲n̲c̲e̲s̲ ̲(̲s̲e̲q̲u̲e̲n̲c̲e̲ ̲a̲c̲c̲e̲s̲s̲ ̲m̲e̲t̲h̲o̲)
The sequence access method makes it possible to read
and write sequences of data by use of CIF access method
or memory access method.
4.2.3.1.7 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲c̲o̲n̲v̲e̲r̲s̲i̲o̲n̲.
This is merely an interface to the subpackage User
Procedures, whichis a collection of display, syntax
and sematic procedures. The USPR subpackage is connected
to the FCO subprocess.
4.2.3.1.8 E̲r̲r̲o̲r̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲ ̲(̲E̲r̲r̲l̲.̲)
During validation this module collects errors and displayes
these when validation of format is inished.
4.2.3.1.9 H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲d̲y̲n̲a̲m̲i̲c̲ ̲m̲e̲m̲o̲r̲y̲ ̲(̲m̲e̲m̲o̲r̲y̲ ̲m̲a̲n̲a̲g̲e̲m̲e̲n̲t̲)̲
The purpose of memory management module is to implement
the necessory dynamic memory allocation for buffers
in VDIA.
4.2.3.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The Dialogue Subpackage is a interpreter which is able
to activate procedures (belonging to a FCO subpackage)
for transformation of data in internal format to a
screen format and visa versa. Only conversion and validation
procedure belongs to the FCO subpackage while storage,display
and other general functions is implemented in the VDIA
subpackage.
4.2.3.2.1 M̲a̲i̲n̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲ ̲o̲f̲ ̲V̲D̲I̲A̲
VDIA is a service coroutine used by "UFCO-like" control
coroutines (SFCO, DIFCO, SEFCO, UFCO) for transfer
and convertion of data between the VD and CIF/memory.
The function of VDIA is controlled by operation buffers
sent to the activation semaphore.
FIGURE 4.2.3.2.1-1
DEPICTS THE MAIN COMPONENTS OF VDIA
The components of VDIA may be grouped into the following
categories:
M̲a̲i̲n̲ ̲L̲o̲o̲p̲ ̲a̲n̲d̲ ̲F̲o̲r̲m̲a̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲
Receives commmands in the activation semaphore and
control the main flow of te execution of commands.
F̲i̲e̲l̲d̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲ ̲A̲c̲c̲e̲s̲s̲,̲ ̲M̲e̲m̲o̲r̲y̲ ̲A̲c̲c̲e̲s̲s̲ ̲a̲n̲d̲ ̲C̲I̲F̲ ̲A̲c̲c̲e̲s̲s̲
Performs storage and retrieval of data stored internalty
in the CAMPS system.
V̲D̲U̲ ̲A̲c̲c̲e̲s̲s̲ ̲M̲e̲t̲h̲o̲d̲ ̲a̲n̲d̲ ̲E̲r̲r̲o̲r̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Performs all input and output to the VD. Performs conversion
between addressing on the VDU (line and field number)
and internal addressing (field type, field replica).
M̲e̲m̲o̲r̲y̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Dynamic allocation and deallocation of memory areas
used as i/o buffers etc.
"P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲"̲
Proedures for syntactic and semantic valication of
input data from the VDU and procedures for conversion
to displayed format for output data to be shown on
the VDU.
4.2.3.2.2 V̲D̲U̲ ̲F̲o̲r̲m̲a̲t̲ ̲a̲n̲d̲ ̲A̲s̲s̲o̲c̲i̲a̲t̲e̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲D̲a̲t̲a̲
The complicated VDIA operations (data input and output)
require that a f̲o̲r̲m̲a̲t̲ has been specified to VDIA by
an output format commnd. A format is the combination
of a scheme of data on the VDU, a scheme of corresponding
data on disk or in memory, and the transformation between
the two schemes. A format is represented by three pieces
of control data:
F̲o̲r̲m̲a̲t̲ ̲H̲a̲n̲d̲l̲e̲r̲'̲s̲ ̲F̲o̲r̲m̲a̲t̲
Used by the format handler to generate the fixed part
of the VDU picture and to define and control the active
input-output fields.
V̲D̲I̲A̲ ̲F̲o̲r̲m̲a̲t̲ ̲M̲o̲d̲e̲l̲
Used by the VDU Access Method module in VDIA in order
to identify the data types for the field on the VDU
and to generate and maintain error codes on the picture.
V̲D̲I̲A̲ ̲F̲o̲r̲m̲a̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲P̲r̲o̲g̲r̲a̲m̲m̲e̲
Used by the Format Control Module in VDIA in order
to control the execution of the operation. The control
programme is written in a special macrocode. It is
interpreted by the format control module. Each instruction
is convented into a call of a procedure using the parametres
specified in the instruction.
4.2.3.2.3 F̲o̲r̲m̲a̲t̲ ̲M̲o̲d̲e̲l̲ ̲a̲n̲d̲ ̲V̲D̲U̲ ̲F̲i̲e̲l̲d̲ ̲T̲y̲p̲e̲
The VDIA Format Models are generated byuse of the offline
Format Model Generator Utility. This utility programme
takes a text file (as preponed by use of the Text Editor
Utility (generating the Format Handler's Format). In
fact, exactly the same input text file is used for
both generato utilities. This file is called the F̲o̲r̲m̲a̲t̲
̲S̲o̲u̲r̲c̲e̲ ̲F̲i̲l̲e̲. This file contains various types of graphic
information (fixed texts, size and position of fields,
video attributes and input/output attributes for the
fields) and beside that a symbolic name efining the
V̲D̲U̲ ̲F̲i̲e̲l̲d̲ ̲T̲y̲p̲e̲ for each field where VDIA can perform
input or output.
For each VDU Field Type the fields having this type
are numbered 1,2,.... according to their order of appearance
on the VDU picture. This F̲i̲e̲l̲d̲ ̲R̲e̲p̲l̲i̲c̲a̲ ̲N̲u̲m̲b̲e̲r̲ together
with the VD Field Type uniquely determines the field.
The pair of integers,
VDU Field Type, Replica
are used internally in VDIA as field identification.
Line number and field number inside the line are used
solely by the VDU Access and Error Message Handlng
Modules.
4.2.3.2.4 F̲o̲r̲m̲a̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲P̲r̲o̲g̲r̲a̲m̲m̲e̲ ̲(̲F̲C̲P̲)̲
To a VDU format belongs a separate FCP for each VDIA
operation which can be executed using the format (OUTPUT
DATA, OUTPUT FORMAT, INPUT DATA). The FCP is prepared
by use of a FCP Conventor tility. The input to the
utility is a text file where the FCP instructions are
written in symbolic form (ref. appendix ).
The main elements in the FCP programming language are
the following:
A̲c̲c̲e̲s̲s̲ ̲t̲o̲ ̲C̲I̲F̲ ̲f̲i̲e̲l̲d̲s̲ ̲o̲r̲ ̲f̲i̲e̲l̲d̲s̲ ̲i̲n̲ ̲m̲e̲m̲o̲r̲y̲ ̲r̲e̲c̲o̲r̲s̲.
This is done by use of standard variables in the language.
When a CIF field variable is referenced the necessary
i/o is automatically executed. There is a fixed number
of memory records references by symbolic names M1,
M2,...... in the FCP. Soe of these records may belong
to "UFCO" i.e. the address of the memory record is
transferred to VDIA in the operation buffer from UFCO.
I̲n̲p̲u̲t̲ ̲f̲r̲o̲m̲ ̲V̲D̲U̲ ̲a̲n̲d̲ ̲s̲y̲n̲t̲a̲c̲t̲i̲c̲ ̲v̲a̲l̲i̲d̲a̲t̲i̲o̲n̲
The FCP allows bundle input of several fields of the
same type to beprocessed in one batch by the syntax
validation procedure. The syntax procedure calls the
procedure STORE FIELD in order to store the converted
values in CIF
4.2.3.2.5 V̲D̲I̲A̲ ̲D̲a̲t̲a̲ ̲L̲a̲y̲o̲u̲t̲
For efficient reasons, VDIA data are separated into
two sections:
- VDIA ̲VAR is he VDIA coroutine record and
contains the actual data. It may
be located anywhere in the process.
- VDIA ̲POINTERS is a set of pointers to subrecords
of VDIA ̲VAR. Its purpose is to facilitate
fast addressing of data in VDIA
̲VAR. It must be locatedjust after
COMONVAR in the process.
As VDIA ̲POINTERS is located at a f̲i̲x̲e̲d̲ address, the
addresses of the separate pointers can be defined as
constants in the VDIA code, even if VDIA is not linked
to the data modules of the process.
Definitions f types, constant addresses and variables
are scetched in the following. As an example, the address
of FCP interpreter data is loaded into R5 by the swell
statement:
INTEGER = R5, P ̲FCPI
FIGURE 4.2.3.2.5-1
VDIA ̲DATA LAYOUT
Definition of VDIA Pointer Record located just after COMONVAR:
TYPE
VDIA ̲PT = RECORD
DISPLAY LOCATION
OF ISPLAY
PROCEDURE
ENTRY
SYNTAX LOCATION
OF SYNTAX
PROCEDURE
ENTRY
SEMAN LOCATION
OF SEMATICS
PROCEDURE
ENTRY
S2 UFCO ACTIVATION
SEM
S3 VDIA ACTIVATION
SEM
INT ̲ERR LOCATION
OF TEP
̲INT ̲ ERROR
ROUTINE
Q ̲ERR: INTEGER; LOCATION
OF QUEUE
ERROR
ROUTINE
STACK: STACK ̲CONTROL ̲BLOCK; VDIA STACK
CONTROL
GLOBAL GLOBAL
VDIA DATA
MAIN MAIN LOOP
CAM CIF ACCESS
FSAM FSAM DESCRIPTOR
MEMREC MEMORY
REC. DESOR
MEM ̲MANAG MEMORY
MANAGEMENT
FCPI FCP INTERPRETER
MODEL FORAT
MODEL
ERROR ̲LIST ERROR
LIST
FORMAT ̲IF VDU I/C
INFO
POINTERS
TO VARIABLES
IN FCO
ITEM ITEM RECORD
VIEW ̲ATTR: INTEGER; VIEW ATTRIBUTES
TEST ̲SAVE: INTEGER; FOR TEST
PURPOSES
END;
V̲D̲I̲A̲ ̲P̲R̲O̲C̲E̲S̲S̲ ̲D̲A̲T̲A̲ ̲A̲R̲E̲A̲ POINTED TO BY VDIA ̲POINTERS:
VAR
VDIA ̲VAR:RECORD VDIA VARIABLES
GLOBAL: GLOBAL ̲DATA; POINTED
TO
BY
P
̲GLOBAL
MAIN: MAIN ̲LOOP ̲DATA;
POINTED TO BY P ̲MAIN
CAM: CAM;
POINTED TO BY P ̲CAM
CAM ̲FIELD ̲ARRAY: ARRAY (1..MAX ̲NO ̲OF ̲MF ̲FIELDS)
OF FIELD;
POINTED TO BY CAM. FIELDS ARRAY CONTROL BLOCK
FSAM: ARRAY ̲CONTROL ̲BLOCK;
POITED TO BY P ̲FSAM
SEQUENCES: ARRAY (1..VDIA ̲NO ̲OF ̲SEQ)
OF SEQ ̲DESCR;
POINTED TO BY FSAM ARRAY CONTROL BLOCK
MEMREC: ARRAY ̲CONTROL ̲BLOCK;
POINTED TO BY P ̲MEMREC
MEM ̲ARRAY: ARRAY (0..VDIA ̲NO ̲OF ̲MEM ̲RECS)
OF MEM ̲REC;
MEM ̲MANAG: MMA;
POINED TO BY P ̲MMA
SLICE ̲ARRAY: ARRAY (1..VDIA ̲NO ̲OF ̲SLICES)
OF SLICE ̲DESCRIPTOR;
FCPI: FCPI ̲REC;
POINTED TO BY P ̲FCPI
BUNDLE ̲ARRAY: ARRAY (0..VDIA ̲NO ̲OF ̲BUNDLES)
OF BUNDLE ̲DESCR;
STORAGE ̲TYPES: ARRAY (0..VDIA ̲NO ̲OF ̲STORAGE ̲TYPES)
OF STOAGE ̲TYPE;
MODEL: MODEL ̲REC;
POINTED TO BY P ̲MODEL
ERROR ̲LIST: ERR ̲REC;
POINTED TO BY P ̲EER ̲LIST
FORMAT ̲IF: FORMAT ̲IF ̲REC;
POINTED TO BY P ̲FORMAT ̲IF;
VDU ̲BUFFER: ARRAY (1..VDIA ̲VDU ̲UF ̲SIZE) OF INTEGER;
MAINTAINED BY VDU I/O
STACK: ARRAY (1..VDIA ̲STACK ̲SIZE) OF INTEGER;
CONTROLLED BY STACK CONTROL BLOCK, POINTED TO BY P
̲STACK
WORKSP: ARRAY (1..VDIA ̲WORK SIZE) OF INTEGER;
MAINTAINED BY MEMORY MANAGEMENT
END; DIA ̲VAR
DEFINITIONS OF CONSTANT ADDRESSES FOR VDIA POINTERS
THE TYPE VDIA ̲PT IS DEFINED IN THE TEP PREFIX:
CONST
T ̲START = ADDR ̲OF ̲COMONVAR + COMONVARSIZE;
P ̲DISPLAY = ADDRESS (PT ̲START VDIA ̲PT.DISPLAY);
P ̲SYNTAX = ADDRESS (PT ̲START VDIA ̲PT.SYNTAX);
P ̲SEMAN = ADDRESS (PT ̲START VDIA ̲PT.SEMAN);
P ̲S2 = ADDRESS (PT ̲START VDIA ̲PT.S2);
P ̲S3 = ADDRESS (PT ̲TART VDIA ̲PT.S3);
P ̲TEP ̲INT ̲ERR = ADDRESS (PT ̲START VDIA ̲PT.INT
̲ERR);
P ̲Q ̲ERR = ADDRESS (PT ̲START VDIA ̲PT.Q
̲ERR);
P ̲STACK = ADDRESS (PT ̲START VDIA ̲PT.STACK);
P ̲GLOBAL = ADDRESS (PT ̲START VDIA ̲PT.GLOBAL);
P ̲MAIN = ADDRESS (PT ̲START VDIA ̲T.MAIN);
P ̲CAM = ADDRESS (PT ̲START VDIA ̲PT.CAM);
P ̲FSAM = ADDRESS (PT ̲START VDIA ̲PT.FSAM);
P ̲MEMREC = ADDRESS (PT ̲START VDIA ̲PT.MEMREC);
P ̲MMA = ADDRESS (PT ̲START VDIA ̲PT.MEM
̲MANAG);
P ̲FCPI = ADDRESS (PT ̲START VDIA ̲PT.FCPI);
P ̲MODEL = ADRESS (PT ̲START VDIA ̲PT.MODEL);
P ̲ERR ̲LIST = ADDRESS (PT ̲START VDIA ̲PT.ERROR
̲LIST);
P ̲FORMAT ̲IF = ADDRESS (PT ̲START VDIA ̲PT.FORMAT
̲IF);
P ̲ITEM = ADDRESS (PT ̲START VDIA ̲PT.ITEM);
P ̲VIEW ̲ATTR = ADDRESS (PT ̲START VDIA ̲PT.VIEW
̲ATTR);
P ̲TESTSAVE = ADDRESS (PT ̲START VDIA ̲PT.TEST
̲SAVE);
I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲V̲D̲I̲A̲ ̲d̲a̲t̲a̲
Initialization of data is stated in the VDIA ̲DAT.S
module. Every pointer is initialized e.g. the pointer
to data for main loop:
VDIA ̲POINTERS.MAIN= ADDRESS (VDIA ̲VAR.MAIN);
Main loop data now can be accessed by use of the pointer.
An example of data access to data could be:
P ̲MAIN INTEGER = R5;
R5 now contains the start address for main loop data.
R5 MAIN ̲LOOP ̲DATA. CURRENT ̲COMMAD = R0;
R0 now contains an information from main loop data.
Further initialization is performed, please refer the
source list VDIA ̲DAT.S
4.2.3.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲,̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
In order to understand the interfaces for VDIA some
knowledge of he internal structure of VDIA - as given
below - is needed.
Format Control, Format Model and Format are data tables.
Format Control is a sort of programme which is interpreted
by VDIA. For complicated VDIA operations (e.g. input
and output) mostlogic is actually found in the Format
Control Programme, which is loaded early in the operation.
Interfaces are shown by bold lines af follows:
1) Semaphore Operation interface between Requesting
Coroutine and VDIA.
2) I/O Interface to fields on the VDU. The interface
goe via the Format Handler and uses the Format
Model as well as the Format.
3) I/O Interface to internal data storage.
4) The semaphore operation contains pointers to data
records. These pointers are accessible from Format
Control. In many cases te actual record structure
is only known by the Requeste and Format Control
and not by the VDIA programme who merely acts as
a mailman.
5) Call of display, syntax and semantics procedures
are controlled by Format Control.
6) The display, syntax nd semantics procedures use
various service routines in VDIA - in particular
for storing data in location determined by Format
control.
7) The procedures may directly access data in some
of the memory records without involving Format
Control (theaddress of the record is given as parametre
in the call of the procedure). This is used e.g.
by the semantic validation of "user" formats.
8) The procedures are after compilation linked with
the requestor code (and not with VDIA). The procedures
ay therefore directly access data in the requestor.
FIGURE 4.2.3.3-1
VDIA AND ITS SURROUNDINGS
4.2.3.7 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
4.2.3.7.1 U̲F̲C̲O̲ ̲V̲D̲I̲A̲ ̲U̲F̲C̲O̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲
S̲E̲M̲A̲P̲H̲O̲R̲E̲ ̲O̲P̲E̲R̲A̲T̲I̲O̲N̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲
In its idle state VDIA waits for the activation semaphore
S3. When a semaphore peration is received, VDIA executes
the command specified. When command execution is completed
VDIA updates the operation:
Sender Coroutine 1d: Changed to VDIA id
PARA 1: Completion code
PARA 2, PARA 3 Pointer to VDIA rsult data
and signals the operation to the requestor activation
semaphore S2. Upon this VDIA returns to the idle state
waiting for the next operation to be send to S3.
Execution of commands involving i/o to the VDU are
relative time consuming ad VDIA will spend most of
the time waiting for completion of VDU i/o. If the
requestor sends a further operation to the semaphore
S3 (e.g. while the execution of the previous operation
is in progress), VDIA kills the current command execution
as fat as posible. The (old) operation is returned
to semaphore S2 with an "error" completion code and
VDIA continues immediately executing the new command.
The VDU is left with undefined data so the intervening
operation should contain a command resetting the VDU
(like "select menu" or "clear VDU")
Note, that all operations send to semaphore S3 are
returned to semaphore S2 - and in the same sequence
as they are received.
The figure on next page lists the commands recognized
by VDIA:
O̲P̲E̲R̲A̲T̲I̲O̲N̲ ̲T̲O̲ ̲V̲D̲I̲A̲ A̲N̲S̲W̲E̲R̲ ̲F̲R̲O̲M̲ ̲V̲D̲I̲A̲
C̲O̲M̲M̲N̲D̲ ̲ ̲ ̲ ̲ ̲ ̲P̲A̲R̲A̲ ̲1̲ ̲ ̲ ̲ ̲P̲A̲R̲A̲ ̲2̲ ̲ ̲ ̲P̲A̲R̲A̲ ̲3̲ ̲ ̲ ̲P̲A̲R̲A̲ ̲1̲ ̲ ̲ ̲ ̲ ̲ ̲P̲A̲R̲A̲ ̲2̲ ̲ ̲P̲A̲R̲A̲
̲3̲
1.
START ̲VDIA % Format % lmit % FF ̲ Completion
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ 1d Area Handle Code
2.
SUSPEND Completion
Code
CLOSE ̲DOWN -"-
DISPLAY ̲MENU %Format
1d -"-
CLEAR ̲VDU -"-
C̲A̲N̲E̲L̲ ̲1̲0̲ ̲ ̲ -"-
3.
OUTPUT ̲FORM. %Format % M1 % M2 -"- % M3 %
M4
1d
O ̲FORMAT ̲
AND ̲DATA %format % M1 % M2 -"- % M3 % M4
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ 1d
4.
INPUT ̲DATA % M1 % M2 -"- % M3 % M4
APPEND % M1 -"-
(SUSPEND) % M1 % M2 -"- % M3 % M4
COPY ̲CIF COPY
TYE -"-
L ̲INSERT Line %Cursor
Count Record -"-
L ̲DELETE Line %Cursor
Count Record -"-
INSERT ̲
GROUP -"- -"-
DELETE ̲
GROUP -"- -"-
ADAI P3 ̲
INPUT % M1 % M2 -"- % M3 % M4
ADAI P3 %Format
OUTPUT 1d % M1 % M2 -"- % M3 % M4
The symbols M1, M2, M3 and M4 denated memory records.
The records M1 and M2 are allocated by the Requestor
before the command is send while the records M3 and
M4 are allocated by he Format Control Programme during
command execution. The VDIA programme does n̲o̲t̲ access
the data in these records but acts merely as a mailman
between Requestor and Format Control by copying the
addresses from and to the semaphore operation. The
sructure of the memory records is therefore a interface
between Requestor and Format Control and will in fact
not be the same for all formats.
The VDIA Programme has 3 basic operational states:
A̲.̲ ̲V̲D̲U̲ ̲a̲n̲d̲ ̲O̲p̲e̲r̲a̲t̲o̲r̲ ̲U̲n̲d̲e̲f̲i̲n̲e̲d̲
The initial state o VDIA. only the START VDIA command
is meaningful. VDIA is returned to this state by the
CLOSE DOWN command.
B̲.̲ ̲V̲D̲U̲ ̲a̲n̲d̲ ̲O̲p̲e̲r̲a̲t̲o̲r̲ ̲D̲e̲f̲i̲n̲e̲d̲ ̲-̲ ̲N̲o̲ ̲A̲c̲t̲i̲v̲e̲ ̲F̲o̲r̲m̲a̲t̲
The idle state for a terminal in use. The following
internal variables in VDIA are define
IFCB for Format Handler (VDU split identification)
Logical Terminal Number
Classification
Special Handling
The commands of categories (2) and (3) are meaningful
in this state. The state is reached by any of the commands:
START ̲VDIA DISPLAY ̲MENU, CLEAR ̲VDU, CANCEL ̲10.
Also this state is reached if VDIA is interrupted during
command execution by an extra operation send to the
activation semaphore.
C̲.̲ ̲A̲c̲t̲i̲v̲e̲ ̲F̲o̲r̲m̲a̲t̲
This state is achieved by any of the commands in category(3)
(i.e. OUTPUT FORMAT or OUTPUT FORMAT AND DATA). In
this state all commands of categories (2), (3) and
(4) are meaningful.
C̲o̲m̲m̲a̲n̲d̲s̲
S̲T̲A̲R̲T̲ ̲V̲D̲I̲A̲: VDIA state is changed from A to B by
means of the parametres in the operation,
and the mnu specified by Format 1d is
displayed. Used by operator log-in.
C̲L̲O̲S̲E̲D̲O̲W̲N̲ Return VDIA to state A. Used by operator
log-out.
D̲I̲S̲P̲L̲A̲Y̲ ̲M̲E̲N̲U̲ The menu specified by Format id is displayed.
VDIA gets state B.
C̲L̲E̲A̲R̲ ̲V̲D̲U̲ The VDU format area is cleare. VDIA
gets state B.
C̲A̲N̲C̲E̲L̲ ̲I̲1̲0̲: VDIA gets state B without operations
on the VDU. Used for fast cancel of
VDU input/output.
O̲U̲T̲P̲U̲T̲ ̲F̲O̲R̲M̲A̲T̲: Outputs the format specified by Format
Id and executes the associated Format
Control Programme for OutputFormat.
VDIA gets state C Usually the neat operation
will be an input data.
OUTPUT FORMAT
A̲N̲D̲ ̲D̲A̲T̲A̲: Outputs the format specified by Format
Id and executes the associated Format
Control Programme for Output Data. VDIA
gets state C.
I̲N̲P̲U̲T̲-̲D̲A̲T̲A̲: oads the Format Control Programme (FCP)
for Input Data belonging to the current
format and executes the FCP. VDIA remains
in state C.
S̲U̲S̲P̲E̲N̲D̲: Same function as Input Data, just another
function code.
L̲I̲N̲E̲-̲I̲N̲S̲E̲R̲T̲: The cursor must be placed in a repeatable
line. The command inserts the specified
number of line copies with empty input
fields after the cursor line. An error
compleion code is returned in the semaphore
operation if the insertion is not possible.
VDIA remains in state C after the insertion
has been performed.
L̲I̲N̲E̲ ̲D̲E̲L̲E̲T̲E̲: The cursor must be placed in a repeatable
line. The specified number of lines
starting t cursor line are deleted.
The command can not delete all lines
of the type pointed to. An error completion
code is returned in the semaphore operation
of the deletion is not possible. VDIA
remains in state C after the insertion
has been performed.
C̲O̲M̲M̲A̲N̲D̲-̲S̲U̲F̲F̲I̲X̲:
The command field of the semaphore operation sent to
VDIA in S3 is structured into two subfields:
- Command Code
- Command Suffix
The command sufix describes special actions to be performed
by VDIA in connection with execution of the command,
such as cleaning up after a previous transaction.
The porrible values of command suffix are defined in
the type VDIA ̲COMMAND ̲SUFFIX in TEP prefix
When the semaphore operation is returned from VDIA to the semaphore
S2, the command suffix field will be zero.
T̲Y̲P̲E̲:
VDIA ̲COMMAND ̲SUFFIX=
(CONTINUE ̲TRANS, new command within
same transaction
NEW ̲TRANS ̲NO ̲CIF, first ommand in a
new transaction without
CIF access.
NEW ̲TRANS ̲CIF); first command in a
new transaction with
CIF access.
4.2.3.7.2 V̲D̲I̲A̲ ̲U̲S̲P̲R̲ ̲V̲D̲I̲A̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The interface between VDIA and USPR is mainly a location
which is stored in VDIA pointers.The locations should
be stored during start up of the process. VDIA activates
the USPR procedure by using the ENTER instruction.
When the ENTER instruction has been performed VDIA
will have set up data, as described below, in the registers.
D̲I̲S̲L̲A̲Y̲
This module consists of a main procedure, which contains
a case for switching to a set of different display
procedures. Each procedure is able to convert data
from internal representation to a format which can
be displayed on the VDU.
The rgister convertions are:
R0 C K Display procedure reference (case label)
R1 C K VDU field type
R3 C Data length in bytes
R Displayed data length in bytes
R4 C K Pointer to ata, which shall be converted
R5 C K Pointer to output data
R6 C Link
S̲Y̲N̲T̲A̲X̲
This module consists of a main procedure, which contains
a case for switching to a set of different syntax procedures.
Each procedure is able to validate one kind of inpu
from the VDU and store in the internal data format.
The register conventions are:
R0 C Syntax procedure
reference (case
label)
R Result: OK, NOT
̲ON
R1 C K Pointer to of field
bundle
R4 C K Pointer to memory
record 1 M.1
(Account)
R5 C K Pointer to memory record 3 M.3
(Semantic record)
R6 C - Link
a field bundle is a record with the layout depicted
below.
FIELD ̲BUNDLE = RECORD
F ̲TYPE VDU FIELD TYPE
REPLICA REPLICA WITHIN FIELD
TYPE OF FIRST FIELD
IN BNDLE
COUNT NUMBER OF FIELDS
IN BUNDLE CONTAINING
DATA
F ̲SIZE: INTEGER; VDU FIELD SIZE.
FOR
VARIABLE FIELDS
IT
IS MAX SIZE
FIELDS ARRAY(FIELD ̲ONE
FIELD ̲ONE) OF
INTEGER; POINTERS TO THE
FIELDS. THERE IS
A
POINTER T EACH
FIELD IN THE BUNDLE
END;
S̲E̲M̲A̲N̲T̲I̲C̲
This module consists of a main procedure, which contains
a case for switching to a set of different semantic
procedures. Each procedure is able to perform a semantic
vaidation of a whole VDU format.
The register conventions are:
R0 C Format number (From last 3 digits in
format name)
R Result: OK, NOT ̲OK
R4 C - Pointer to memory record 1 (M.1)
R5 C - Pointer to memory record 3 (M.3)
R6 C - Link
4.2.3.4.1 V̲D̲I̲A̲ ̲M̲A̲I̲N̲
The VDIA MAIN module contains the main loop for the
VDIA coroutine, with the main waiting point for communication
with UFCO. Furthermore the module contains a procdure
with waiting point for VDU I/O completion.
4.2.3.4.1.1 V̲D̲I̲A̲ ̲M̲a̲i̲n̲ ̲L̲o̲o̲p̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.3.4.1.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̲
VDIA Main Loop contains the initial entry point for
the VDIA coroutine.
When VDIA Main Loop has received an oeration from UFCO
it will initiate the appropriate function.
If the command ca read/write to the VDU, Main
Loop will load the FCP associated to format, which
is given in the operation and the command. Then it
will start interpreting of the FP.
At other commands it will start initiate function in
other modules of VDIA. Depending on completion codes
from the interpretation of the FCP or execution of
functions in other VDA modules the Main Loop will send
answer to UFCO.
Execution of commands which are extensions to VDIA
Main Loop, are called with the following conventions:
R0 - R Completion code (internal VDIA
value)
R1 C - Parametre 1 from operation
R2 C R Parametre 2 from operation
R3 C R Parametre 3 from operation
R5 C - Command code
R6 C - Link
4.2.3.4.1.1.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
PROCEDURE N̲E̲W̲ ̲S̲T̲A̲T̲E̲
(R2 C K COMMAND COD
R3 C VDIA STATE
R NEW STATE CR -1 FOR ILLEGAL
R6) C LINK
COMPUTES NEW STATE FROM OLD STATE AND COMMAND CODE.
IF THE COMMAND IS ILLEGAL A STATE OF -1 IS RETURNED.
PROCEDURE E̲R̲R̲O̲R̲ ̲S̲T̲A̲T̲E̲
(R0 R COMPLETION CODE FOR ANSWER TO FCO
1 C COMPLETION CODE (INTERNAL VDIA)
R2 C K COMMAND CODE
R3 C VDIA STATE
R NEW STATE
R6) C LINK
COMPUTES THE STATE TO BE USED AFTER COMMAND TERMINATED
IN ERROR.
CALLS RESET FUNCTIONS IF REQUIRED.
COMPUTES THE ERROR CODE TO BE USED IN THE ANSWER TO
FCO.
PROCEDURE M̲O̲V̲E̲ ̲O̲R̲M̲A̲T̲ ̲I̲D̲
(R1 C K %FORMAT ID
R6) C LINK
MOVES FORMAT ID TO GLOBAL DATA. EXTRACTS THE FORMAT
NUMBER FROM THE LAST THREE DIGITS IN THE FORMAT ID
AND STORES THE VALUE IN GLOBAL DATA.
PROCEDURE R̲E̲A̲D̲ ̲F̲O̲R̲M̲A̲T̲
(R1 C BYTE COUNT
R2 C K BYTE OFFET IN FILE (15: 0)
R3 C K BYTE OFFSET IN FILE (31:16)
R4 C K % DESTINATION
R6) C LINK
READS A SPECIFIED PART OF THE VDIA CONTROL FILE WHICH
CONTAINS MODELS AND FCPS FOR ALL USER FORMATS. BYTE
COUNT (R1) SPECIFIES THE AMOUT TO BE INPUT, BYT OFFSET
(R23) SPECIFY START POSITION IN FILE, WHILE DESTINATION
(R4) IS A WORD ADDRESS.
PROCEDURE I̲N̲S̲T̲A̲L̲L̲ ̲R̲E̲C̲ ̲P̲A̲R̲T̲
(R2 C WANTED PART: INS ̲MOD ̲OUT: MODEL AND FCP
̲OUT
INS ̲IN : FCP-IN
R4 R % MEMORY BUFFER
R6 C LINK
RELEASES MEMORY BUFFER(S) USED FOR THE MENTIONED PURPOSE.
RESERVES A MEMORY BUF BY CALL OF "GET ̲ALL ̲MEMORY" AND
INPUTS THE REQUESTED PART OF FCP ̲FILE RECORD (FOR CURRENT
FORMAT).
NOE: THE VARIABLES IN MAIN ̲LOOP ̲DATA:
MODEL ̲START, FCP ̲START, FCP ̲SIZE ARE NOT UPDATED.
***
PROCEDURE U̲P̲D̲A̲T̲E̲ ̲I̲T̲E̲M̲S̲
(R6) C LINK
"PRIMARY ̲ITEM" AND "SECONDARY ̲ITEM" ARE MOVED FROM
FCO DATA TO VDIA GLOBAL VARIABLES.
PROCEDURE D̲E̲F̲I̲N̲E̲ ̲M̲1̲ ̲M̲2̲
(R2 C K ADDRESS OF MEMORYRECORD 1
R3 C K ADDRESS OF MEMORY RECORD 2
R6) C LINK
CALLS "DEFINE ̲MEMREC" IN ORDER TO DEFINE THAT MEMORY
RECORDS M1 M2 HAVE THE ADDRESSES SPECIFIED.
PROCEDURE G̲E̲T̲ ̲M̲3̲ ̲M̲4̲
(R2 R ADDRESS OF MEMORY RECORD M3
R3 R ADDRESS OF MEMORY RECOD M4
R6) C LINK
CALLS THE FUNCTION "GET ̲MEMREC ̲ATTR" IN ORDER TO FIND
THE ADDRESSES OF MEMORY RECORDS M3 M4.
4.2.3.4.1.1.2 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
TYPE MAIN ̲LOOP ̲DATA = RECORD
VDIA CONTROL FILE DESCRIPTOR:
CONTROL ̲FDCB FDCB INDEX FOR
FILE
NO ̲OF ̲RECORDS NO OF RECORDS IN
FILE
MODEL ̲MX MAX WORD SIZE OF
MODEL
FCP ̲OUT ̲MAX MAX WORD SIZE OF
FCP ̲OUT
FCP ̲IN ̲MAX MAX WORD SIZE OF
FCP ̲IN
CTRL ̲REC ̲SIZE: INTEGER RECORD SIZE IN
BYTES
MODEL AND FCP CONTROL INFO
MODEL ̲START START ADDR FOR
MODEL
FCP ̲START START ADDR FOR
FCP A
ZERO
INDICATES
THAT
NO
BUFFER IS ALLOCATED.
FCP ̲SIZE: INTEGER SIZE IN WORDS ON
FCP BUFFER
COMMAND AND STATE
CURRENT ̲COMMAND CURRENT COMMAND
CODE
PREVIOUS ̲COMMAND PREVIOUS COMMAND
CODE
COMMAND ̲SUFFIX CURRENT COMMAND
SUFFIX
CIF ̲ACCESS COMMAND USES CIF
ACCESS
CURRENT ̲OPERATION POINTERS SEMAPHORE
NEXT
̲OPERATION: INTEGER OPERATIONS
RECEIVED
FROM
FCO.
LONG EXIT:
LONG ̲EXIT ̲RETURN RETURN ADDRESS
LONG ̲EXIT ̲STACKPT STACK POINTER
VDIA ̲STATE: INTEGER STAT
END
P ̲MAIN POINTS TO A RECORD OF THIS TYPE
4.2.3.4.1.2 S̲t̲a̲c̲k̲ ̲E̲r̲r̲o̲r̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.3.4.1.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̲
CALLED IN THE ERROR EXIT FOR STACK OVERFLOW AS FOLLOWS:
SWITCH CSP ( (P ̲STACK = R0) INTEGER, (SIZE (WORK)
) = R7)
ERROR ̲OK TO
ERROR: STACK ̲ERROR (R6)
END
THE PROCEDURE CALLS TEP ̲INT ̲ERROR. THE REGISTERS MUST
CORRESPOND TO THE ORDER SEQUENCE ABOVE.
4.2.3.4.1.2.2 o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲sp̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) STACK ̲ERROR
b) STACK ̲ERROR (R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲c̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
R6 LINK destroyed
(R0 see description above)
(R7 see description above)
R̲e̲t̲u̲r̲n̲ ̲r̲e̲g̲i̲s̲t̲e̲r̲s̲
F̲a̲t̲a̲l̲ ̲e̲r̲r̲o̲r̲s̲
Stack overflow (always)
4.2.3.4.1.2.3 M̲o̲d̲u̲l̲e̲ ̲c̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
None.
4.2.3.4.1.3 L̲o̲n̲g̲ ̲E̲x̲i̲t̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
THE PROCEDURE JUMPS BACK TO MAIN LOOP WITH SPECIFIED
COMPLETION CODE. THE LINK REGISTER IS DUMMY AS THE
PROCEDURE ILL NEVER RETURN TO CALLER.
M̲o̲d̲u̲l̲ ̲i̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲s̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) LONG ̲EXIT
b) LONG ̲EXIT (R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲c̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
R0 completion code (kept)
R6 Link (destroyed)
R̲e̲t̲u̲r̲n̲ ̲r̲e̲g̲i̲s̲t̲e̲r̲s̲
R2 Para 2 in answer operation
R3 Para in answer operation
F̲a̲t̲a̲l̲ ̲e̲r̲r̲o̲r̲s̲
None.
4.2.3.4.1.4 W̲a̲i̲t̲ ̲V̲d̲u̲ ̲I̲ ̲O̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
CALLS ASSOCIATE IN ORDER TO ASSOCIATE THE OPERATION
TO THE VDIA ACTIVATION SEMAPHORE S3 - AND WAITS FOR
THE SEMAPHORE.
IF THE SAMEOPERATION IS RECEIVED BACK ON WAIT THE FOLLOWING
IS DONE:
WAIT ̲SYSTEM ̲CALL IN ORDER TO GET RESULT OF FORMAT
̲HANDLER I-O
IF RESULT = OK THE RETURN TO CALLER
ELSE LONG ̲EXIT.
IF ANOTHER OPERATION IS RECEIVED IN S3 THE RECEIVED
OPERATION POINER IS STORED IN NEXT ̲OPERATION; THE CURRENT
FORMAT ̲HANDLER OPERATION IS CANCELLED, AND A LONG ̲EXIT
IS MADE WITH COMPLETION CODE = COMMAND ̲INTERRUPTION.
M̲o̲d̲u̲l̲e̲ ̲i̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) WAIT ̲VDU ̲I ̲O (RET ̲SYS ̲0,
RET ̲SYS ̲1,
RET ̲SYS ̲2,
RET ̲SYS ̲3,
RET ̲SYS ̲4,
SEM ̲PTR: INTEGER)
b) WAIT ̲VDU ̲I ̲O(R0, R1, R2, R3, R4, R5, R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲c̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
(R0 - R RETURN FROM WAIT ̲SYSTEM ̲CALL
R1 - R RETURN FROM WAIT ̲SYSTEM ̲CALL
R2 - R RETURN FROM WAIT ̲SYSTEM ̲CLL
R3 - R RETURN FROM WAIT ̲SYSTEM ̲CALL
R4 - R RETURN FROM WAIT ̲SYSTEM ̲CALL
R5 C K POINTER TO SEMAPHORE OPERATION
R6) C - LINK
F̲a̲t̲a̲l̲ ̲e̲r̲r̲o̲r̲s̲
Errors from format handler (exept VDU ̲SPLIT ̲FAILED,
insert and delete not allowed).
4.2.3.4.2 F̲o̲r̲m̲a̲t̲ ̲P̲r̲o̲g̲r̲a̲m̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲
The Format Programme Interpreter executes the Format
Control Programme under control of VDIA Main Loop.
FCP is a variable length byte string, which mut have
been read into a memory area by Main Loop before FCI
is activated.
When activated from Main Loop, FCI scans the FCP sequentially
and executes the commands one by one. When an END command
or the physical end of FCP is reached, whatever occus
first, FCI returnes to Main Loop.
4.2.3.4.2.1 Format Control Programme Interpreter Main
4.2.3.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̲
INTERPRETATE THE LOADED SEGMENT OF THE FORMAT ̲CONTROL
̲PROGRAMME (FCP).
THE FCP I CONSIDERED AS A BYTE ̲ARRAY, WITH COMMANDS
(INSTRUCTION ̲CODES) ON BYTE ̲BOUNDARY. PARAMETRES TO
THE COMMAND (IF ANY) ARE PACKED IMMEDIATELY BEHIND
THE COMMAND. FIRST BYTE IS ASSUMED TO BE A COMMAND.
INTERPRETATION IS TERMINATED WHEN A EXIT ̲COMMAND R
LIMIT OF THE BYTE ̲ARRAY IS REACHED.
THE COMPLETION CODE IS BASED ON VALIDATION RESULTS
FROM SYNTAX/SEMANTIC PROCEDURE.
4.2.3.4.2.1.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) FCPI ̲MAIN (COMMAND,
FCP ̲PT,
MAX ̲INDEX: INTEGER
CC: INTEGER
b) FCPI ̲MAIN (R0, R1, R4, R5, R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲c̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
R1 Command from FCO
R4 Pointer to first word in loades FCP segment
R5 Max number of FCP bytes (-1) to be interpreted
R6 Kept
R̲e̲t̲u̲r̲n̲ ̲r̲e̲g̲i̲s̲t̲e̲r̲s̲
R0 Cmpletion codes
R1 - R5 Kept
R6 Destroyed
R7 Kept
F̲a̲t̲a̲l̲ ̲e̲r̲r̲o̲r̲s̲
(see appendix XX)
4.2.3.4.2.1.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
PROCEDURE
EVALUATE ̲CMD
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
(
R1 - R FCP ̲COMMAND: FCP ̲CMD
R5 C K % FCPI ̲DESCR
R6 - - LINK
) SKIP ̲EXEC
Narrative (Functional):
Auxilliary procedure. Determines if command is to be
skipped or executed. Further the trailing parametres
(if any) are moved to word boundary. Programme-Counters
(current, next) are updated.
PROCEURE
INSTR ̲LENGTH
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
(
R3 C R INSTRUCTION CODE / INSTRUCTION LENGTH
R6 - - LINK
)
Narrative (Functional):
Auxilliary procedure that returns the instruction length
(in bytes, includng the instr. code) corresponding
to the specified instruction code.
Narrative (Design):
The procedure contains an inline table of instruction
̲lengths.
Note:
The table are ordered according to the scalar ̲type
FCP ̲CMD!
The inline table must bechecked manually, when FCP
̲CMD is changed!
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Local PROCEDURE
GET ̲LENGTH ( INSTR ̲LENGTH INTEGER R6 )
Narrative: This is a dummy procedure used to fetch
one word from an inline table
4.2.3.4.2.1.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
VDIA pointers
VDIA data
4.2.3.4.2.1.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
As the length of parametres are uniquely related to
the command, update of the PROGRAMME ̲OUNTER (PT) may
be done before branching to "EXECUTE COMMAND". Data
from FCPI ̲MAIN to the underlying layer of "EXECUTE"
-procedures (one to each command) is handed over via
a FCPI ̲DESCRIPTOR (stacked). Data from "EXECUTE"-procedures
to FCPI ̲MAIN ar handed-over via a flag-array (static
located by linker) or - if "EXECUTE"-procedure concerns
if, repeat, until, while, endwhile or exit commands
- via FCPI ̲DESCRIPTOR.
The FCPI ̲DESCRIPTOR contains mainly: index to CURRENT/NEXT
̲COMMAND, LOOP ̲CONTOL and parametres.
These parametres are, for further SWELL ̲PROCESSING,
moved to word boundary. No jump-forward is implemented,
i.e. a WHILE ̲LOOP is bypassed by repeated skips of
single commands until the ENDWHILE ̲COMMAND is reached.
While..endwhle loops should not be nested (no run-time
check). Repeat...until loops can be nested to a level
determined by constant defined in "FCP ̲PREFIX".
However, a WHILE ̲LOOP may be nested within a REPEAT
̲LOOP (or visa versa).
4.2.3.4.2.2 Format Contro Programme Interpreter Input
S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
4.2.3.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̲ ̲(̲M̲o̲d̲u̲l̲e̲ ̲d̲e̲s̲i̲g̲n̲)̲
X̲ ̲I̲N̲I̲T̲ ̲B̲U̲N̲D̲
Narrative (Functional):
Executes the FCP ̲INSTRUCTION INIT ̲BUNDLE. Ie.
Initializes a bundle. Mandatory for urther processing
of specified bundle.
Narrative (Design):
Unpacks trailing parametres to command. Unpacked parametres
are re-arranged for call of auxilliary procedure INIT
̲BUNDLE.
X̲ ̲I̲N̲P̲ ̲F̲I̲E̲L̲D̲
Narrative (Functional):
Executes the FCP ̲INSTRUTION INPUT ̲FIELD. Ie. a single
field of specified VDU ̲TYPE from the VDU. The field
is validated by specified SYNTAX ̲PROCEDURE, which uses
specified variable when storing results.
Flag VDU ̲RES is updated.
Narrative (Design):
A special bundle (BUDLE ̲ZERO, not accessable from FCP)
is SET ̲UP ro the SYNTAX ̲PROCEDURE.
X̲ ̲I̲N̲P̲ ̲N̲X̲T̲
Narrative (Functional):
Executes the FCP ̲INSTRUCTION INPUT ̲NEXT. Ie. a single
field of specified VDU ̲TYPE from the VDU. The field
is validated by specified SYNTAX ̲ROCEDURE, which stores
results in specified sequence.
Flag VDU ̲RES is updated.
Narrative (Design):
A special bundle (BUNDLE ̲ZERO, not accessable from
FCP) is SET ̲UP for the SYNTAX ̲PROCEDURE.
X̲ ̲I̲L̲P̲ ̲N̲X̲T̲ ̲B̲U̲N̲D̲
Narrative (Functional):
Executes the FCP ̲INSTRUCTION INPUT ̲NEXT ̲BUNDLE. The
bundle in concern must have been initialized.
The next bundle of VDU ̲TYPE is input fom VDU and inserted
into bundle. If bundle did not become full, no more
action is taken. Otherwise, if bundle did become full,
the field(s) is (are) validated and results stored
into Flag VDU ̲RES is updated. Sequence.
Note: No resources are relase. Consequently, this command
should never be the last concerning specified bundle
(refer X ̲FLUSH ̲BUND).
X̲ ̲I̲N̲P̲ ̲S̲E̲Q̲.
Narrative (Functional):
Executes the FCP ̲INSTRUCTION INPUT ̲SEQUENCE. Equivalent
to repeated calls of INPUT ̲NEXT until all fields4̲7̲9̲4̲A̲…00…CPS/SDS/039
…00…vhn …00…HDK
…00…4.2.3 …00…0̲2̲…00…0̲4̲…00…8̲4̲…00…1̲1̲…00…4̲6̲…00… ̲ ̲3̲9̲…00…2̲5̲…00…1̲2̲7̲7̲4̲6̲…00…09…00…10…00…84…00…15…00…50…00…
…00…01…00… 7…00…0̲9̲…00…1̲0̲…00…8̲4̲…00…1̲4̲…00…5̲1̲…00…10…00…10…00…84…00…11…00…42…00…0460A…00… 71…00… ̲ ̲4̲1̲…00…52…00… 1288…00…1̲3̲4̲6̲4̲7…00……09……00……01……00……11……02……00……10……00……01……10…F'…10……11…
…80…*̲…8a…7 …00……00……00……00……00……00……01…8
j…01……86……00……00……00……00…3…02……00……00…3
2…0d…2…07…1…00…1…06…0…0c…0…01…0 0…05…/…09…/…01….…08….…0d….…0e….…02….…07…-…0a…-…00…-…05…,…0b…,…0c…,…02…+…08…+…0f…+ *…0a…*…00…*…86…1
…02…
…02…
…02…
…02…CPS/SDS/039
…02…840601…02……02…#
USER VDU
DETAILED DESIGN SPECIFICATION…02…ISSUE 1…02…CAMPS
4.2.3 VDU Dialogue(VDIA) ....................
4.2.3.1 Functional Specification ...........
4.2.3.1.1 Control of main flow (VDIA main
loop) ..........................
4.2.3.1.2 Interpretation of format control
"programmes" ...................
4.2.3.1.3 Input from/output to VDU (VDU
access method) .................
4.2.3.1.4 Read from/write to CIF (CIF
access method) .................
4.2.3.1.5 Rea from/write to memory
(memory access method) .........
4.2.3.1.6 Read/write from sequences
(sequence access method) .......
4.2.3.1.7 Validation and conversion. .....
4.2.3.1.8 Error hanling (Errl.) .........
4.2.3.1.9 Handling of dynamic memory
(memory management) ............
4.2.3.2 Software Structure .................
4.2.3.2.1 Main Components of VDIA ........
4.2.3.2.2 VD Format and Associated
CONTROL Data ...................
4.2.3.2.3 Format Model and VDU Field Type
4.2.3.2.4 Format Control Programme (FCP) .
4.2.3.2.5 VDIA Data Layout ...............
4.2.3.3 Data low, Control Structure .......
4.2.3.3.1 Subpackage Interface .............
4.2.3.3.1.1 UFCO VDIA UFCO INTERFACE .....
4.2.3.3.1.2 VDIA USPR VDIA Interface .....
4.2.3.4 Module Specification ...............
4.2.3.4.1 VDIA MAIN ......................
4.2.3.4.1.1 VDIA Main Loop Specification
4.2.3.4.1.1.1 Functional Specification
4.2.3.4.1.1.3 Module Components ......
4.2.3.4.1.1.2 Data Description ......
4.2.3.4.1.2 Stack Error Specification ..
4.2.3.4.1.2.1 Functional Specification
4.2.3.4.1.2.2 Module Interface .......
4.2.3.4.1.2.3 Module components ......
4.2.3.4.1.3 Long Exit Spcification ....
4.2.3.4.1.4 Wait Vdu I O Specification .
4.2.3.4.2 Format Program Interpreter .....
4.2.3.4.2.1 Format Control Progamme
Interpreter Main spec. .....
4.2.3.4.2.1.1 Functional Specification
4.2.3.4.2.1.2 Module Interface .......
4.2.3.4.2.1.3 Module Components ......
4.2.3.4.2.1.4 Data Description ......
4.2.3.4.2.1.5 Module Design ..........
4.2.3.4.2.2 Format Control Programme
Interpreter Input Spec. ....
4.2.3.4.2.2.1 Functional Specification
4.2.3.4.2.2.2 Module Interface .......
4.2.3.4.2.2.3 Module
Components ......
4.2.3.4.2.2.4 Data Description .......
4.2.3.4.2.2.5 Module Design ..........
4.2.3.4.2.3 Format Control Programme
Interpreter Disp spec. .....
4.2.3.4.2.3.1 Functional Specification
(Module Design) ........
4.2.3.4.2.3.2 Module Interface .......
4.2.3.4.2.3.3 Module Components ......
4.2.3.4.2.3.4 Data Description .......
4.2.3.4.2.3.5 Module Design ..........
4.2.3.4.2.4 Format Control Programme
Contr Specification ........
4.2.3.4.2.4.1 Functional Specification
(Module Design) ........
4.2.3.4.2.4. Module Interface .......
4.2.3.4.2.4.3 Module Components ......
4.2.3.4.2.4.4 Data Description .......
4.2.3.4.2.4.5 Module Design ..........
4.2.3.4.2.5 Format Control Programme
Seq Specfication ..........
4.2.3.4.2.5.1 Functional Specification
(Module Design) ........
4.2.3.4.2.5.2 Module Interface .......
4.2.3.4.2.5.3 Module Components ......
4.2.3.4.2.5.4 Data escription .......
4.2.3.4.2.5.5 Module Design ..........
4.2.3.4.2.6 Format Control Programme
Misc Specification .........
4.2.3.4.2.6.1 Functional Specification
4.2.3.4.2.6.2 ModuleInterface .......
4.2.3.4.2.6.3 Module components ......
4.2.3.4.2.6.4 Data Description .......
4.2.3.4.2.6.5 Module Design ..........
4.2.3.4.2.7 Format Control Programme Aux
Specification .............
4.2.3.4.2.7.1 Functional Specification
4.2.3.4.2.7.2 Module Interface .......
4.2.3.4.3 VDU Access Method ..............
4.2.3.4.3.1 Vdu Access Method Main
Specification .............
4.2.3.4.3.1.1 Functional Specification
4.2.3.4.3.1.2 Module interface .......
4.2.3.4.3.1.3 Module Components ......
4.2.3.4.3.1.4 Data Description .......
4.2.3.4.3.2 Vdu Access Method Mdel
Specification ..............
4.2.3.4.3.2.1 Functional Specification ...
4.2.3.4.3.2.2 Module Interface .......
4.2.3.4.3.2.3 Module Components ......
4.2.3.4.3.2.4 Data Description ......
4.2.3.4.3.3 Vdu Access Method Io
Specification ..............
4.2.3.4.3.3.1 Functional Specification
4.2.3.4.3.3.2 Module Interface .......
4.2.3.4.3.3.3 Module Components ......
4.2.3.4.3.3.4 Data Description .......
4.2.3.4.3.4 Vdu Access Method Errl
Specification ..............
4.2.3.4.3.4.1 Functional Specification
4.2.3.4.3.4.3 Module Components ......
4.2.3.4.3.4.4 Data Description .......
4.2.3.4.4 Cif Access Method ..............
4.2.3.4.4.1 Cif Access Method
Specification ..............
4.2.3.4.4.1.1 Functional Specification
.2.3.4.4.1.2 Module Interface .......
4.2.3.4.4.1.3 Module Components ......
4.2.3.4.4.1.4 Data Description .......
4.2.3.4.5 Memory Access Method - Mem Acc.
4.2.3.4.5.1 Memory Access Method
Specification ..............
4.2.3.4.5.1.1 Functional Specification
4.2.3.4.5.1.2 Module Interface .......
4.2.3.4.5.1.3 Module Components ......
4.2.3.4.5.1.4 Data Description .......
