⟦8ee76ce00⟧

TextFile

T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_ _

1. INTRODUCTION .......................................... 1

2. PARAMETER FORMAT ...................................... 2

3. COMMAND FILE SYNTAX ................................... 3

4. OPERATOR COMMUNICATION ................................ 7

5. CHAINED PROGRAMS ...................................... 8

A_P_P_E_N_D_I_X_

A. REFERENCES ............................................ 11
\f

ii
\f

1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_C_T_I_O_N_ 1.

The EXEC program is the DOMUS batch processor module, which exe-
cutes utility-program calls and S-functions in a sequential user
defined sequence. Commands are supplied by the user as ASCII
characters on a discfile or external device.

In contrary to the DOMUS INT (ERPRET) function each termination
of a utility-program is awaited and the success of the call is
checked. In case of error the whole job is aborted is specified
so by the user in the EXEC call.

The command file is read to the internal workfile .XEC before
interpretation, hereby releasing the input device for use in the
job.

2_._ _ _ _ _ _ _ _ _P_A_R_A_M_E_T_E_R_ _F_O_R_M_A_T_ 2.

The syntax of the call follows the general rules given in 2,
and the parameters are:

EXEC IN.<filename' LIST.<filename' STOP<boolean' CONT.<filename'

IN: This is the file containing a number of lines with nor-
mal S-functions, internal commands or utility calls in
the same format as used when entering commands to the
S-process from the operator console. The syntax check
is left to the S-process, and the function of the EXEC
program is mainly to split the file into single commads
send for interpretation and execution at the S-process.
LIST: A log of the commands is produced on this file. The
file can not be used by programs loaded during the job.
STOP: If this parameter equals YES, a check is performed on
each utility termination, and if the program reports a
non-sucessful termination, the whole job is terminated
with an error message.
CONT: If specified, this file must be a command file for
DOMUS. When the EXEC command FINISH is executed, the
EXEC program will be removed, and the operating system
is requested to interpret this file.
Default: EXEC IN.PTR LIST.<0'...<0' STOP.NO CONT.<0'...<0'

3_._ _ _ _ _ _ _ _ _C_O_M_M_A_N_D_ _F_I_L_E_ _S_Y_N_T_A_X_ 3.

The only check performed by the EXEC program is a check on the
identifier found as the first item on each line, and a final
check is left to the operating system and the programs loaded.

The syntax is then the one described in 1 and 2, and the only
operation done by the EXEC module is the line separation, as the
lines are handed over to the S-process for execution line by
line.

However, following exception exists:

- BEGIN and END commands are blind and the rest of the line is
skipped, hereby left for comments.

- A DRIVE function implies that following program-loads are per-
formed from the catalog unit given as parameter, until a new
DRIVE function is found, and the END function will not reset
the drive number to zero.

- A CONNECT command implies that the filenames stated in the
following utility program calls will be interpreted as belong-
ing to the stated catalog. Note, that an END-command has no
effect in the command file.

- A RELEASE command will change the current catalog to the cata-
log that was current, when the EXEC program was loaded. Note,
that if connection to the main catalog is wanted, the command
CONNECT CAT must be used.

- Comments can be given anywhere in the command file as !<any
number of characters except!'!. The whole comment is skipped
and replaced by a single space, but transferred to the list-
file unchanged. Newline characters in a comment string have no
effect.

- LIST functions are ignorred by the S-process.
\f

- Each line must not exceed 500 characters in length, including
comments which are counted as one character.

- Characters which are interpreted as blind or illegal by the
S-process are skipped.

- Tabulation characters are converted to spaces on the listfile.

The action taken by the EXEC module depends on the identifier
found as the first item on each line, and is given in the below
table. Internal functions can be viewed on as utility functions,
although no load is performed.

B_E_G_I_N_ The line is ignored by the EXEC program.

B_O_O_T_ The line is send to the S-process for execution. If the
command is accepted, the DOMUS system, including the
EXEC-program, is overwritten and properly termination of
log output or job can not be expected.

C_L_E_A_N_ The line is send to the S-process.

C_L_E_A_R_ The line is send to the S-process.

C_O_N_N_E_C_T_ The current catalog is changed to the one given as par-
ameter. Note that the current catalog is not changed
even if an END-command is met.

D_R_I_V_E_ The drive-number specified as a parameter will be the
catalog unit from where the following program loads are
performed. Note that the drive-number is not changed
even if an END command is found in contrary to normal
use of console entered commands.

Before a DRIVE command or a load from a catalog unit
different from zero is used, an INIT command should be
given. Only decimal drive numbers are allowed.

E_N_D_ The command is ignored by the EXEC program. \f

F_I_N_I_S_H_ This is an internal command. Job execution is termina-
ted, and the EXEC program is removed from the core, and
all processes loaded during run is removed too by the
operating system.

The command must be the last in the command file.

F_R_E_E_ The line is send to the S-process.

G_E_T_ The line is send to the S-process.

I_N_I_T_ The line is send to the S-process.

I_N_T_ The line is send to the S-process.

K_I_L_L_ The line is send to the S-process.
The process to kill must not have messages pending at
the EXEC process, else this is breaked with breakcause
1.

L_I_S_T_ Ignored by the operating system.

L_O_A_D_ The line is send to the S-process.
LOAD function can be used for utility program loads like

LOAD (DELETE PIP)

but the termination of the utility program is not awai-
ted. The termination messages will, however, be granted
and the utility program is removed when the message is
send. If the utility function has not terminated when
EXEC program finds a FINISH command, it is removed un-
conditionally.

P_A_U_S_E_ This is an internal command. A number sign (#) is output
on the operator console, and the EXEC process waits for
operator intervention. If operator inputs STOP the EXEC
process will stop execution as if a FINISH command was\f

met, and the outputs the message >EXECUTION STOPPED BY
THE OPERATOR>, else the execution is continued.

R_E_L_E_A_S_E_ Changes the current catalog to the one that was current
catalog of DOMUS, when EXEC was called. This is not
neccessarily the main catalog. To change to the main
catalog, use the command CONNECT CAT.

S_T_A_R_T_ The line is send to the S-process.

S_T_O_P_ The line is send to the S-process.

<any other name' The line is send to the S-process as a utility
program load function. A termination message
from the utility module is awaited, and if this
indicates an unsuccessful run the execution is
aborted is STOP.YES is specified, else job
execution is continued. If the job is aborted
the text >UTILITY PROGRAM ERROR, PROGRAM <name'
is output on the operator console.

Note:
Do not load other modules than utility programs
in this way, as a missing termination message
will hang up EXEC for ever.
\f

4_._ _ _ _ _ _ _ _ _O_P_E_R_A_T_O_R_ _C_O_M_M_U_N_I_C_A_T_I_O_N_ 4.

The EXEC program accepts input from operator during run.

If operator inputs STOP the execution of the command-file is
aborted and the program outputs

EXECUTION STOPPED BY OPERATOR

If a PAUSE command is met a numbersign (#) is output, and the
program waits for input. If the operator inputs STOP the execu-
tion is aborted as above explained, else the execution is con-
tinued.

Example (input marked with _):

c_o_n_t_r_o_l_ _G_
'E_X_E_C_
S_T_O_P_
EXECUTION STOPPED BY OPERATOR
'S
FINISH EXEC \f

5_._ _ _ _ _ _ _ _ _C_H_A_I_N_E_D_ _P_R_O_G_R_A_M_S_ 5.

When utility programs sends a termination message, this message
can hold a string of commands, which is requested to be interpre-
ted and executed when removal of the program from core has taken
place.

The EXEC module interprets such commands as if they were present
in the operator specified command file after the previous execu-
ted line, and the commands must therefore obey the rules given in
section 3. The list file output is ignored during execution of
these commands, and they are invisible to operator, as if the
requesting program was still running, and can be repeated any
number of times, only limited by disc space.

Example:

Command file PROG1 request PROG2 request PROG3 request

PROG1
PROG2
PROG4
PROG5
PROG3
PROG6

Resulting sequence of program calls:

PROG1
PROG2
PROG4
PROG5 Not listed on log.
PROG3
PROG6 \f

If the file TESTC contains the text:

CHATR ASC1
EDIT ASC1 ! UNPROTECT, EDIT AND !
CHATR ASC1 PW ! PROTECT SOURCE 1 !
PAUSE ! WAITING FOR READER !
COPY PTR ASC2 ! READ ,EDIT AND !
EDIT ASC2 ! PROTECT SOURCE 2 !
CHATR ASC2 PW
DOMAC LIST.LPT BIN.R1 ASC1
DELETE XXX
DOMAC LIST.XXX BIN.R2 ASC2
PRINT XXX
PRINT XXX ! PROCEDURE TWO LISTING OF ASC2 !
DELETE TEST
LINK TEST LOG.LPT FORM.R IN.R1 R2
TEST ! LOAD THE PROGRAM !
FINISH

the call EXEC TESTC

will call the Editor twice, assemble the two sources and load the
resulting program. Listing of the code is produced for both
modules, with two copies of the source read from paper tape.
\f

A_P_P_E_N_D_I_X_ _A_ _-_ _R_E_F_E_R_E_N_C_E_S_

1 DOMUS User>s Guide, Part 1.

2 DOMUS User>s Guide, Part 2.
\f

T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_

1. INTRODUCTION ........................................... 1
1.1 Structure of this Manual .......................... 2
1.2 Notes on Notation and Terminology ................. 2

2. RC8000 TERMINAL PROCESS INTERFACE ...................... 4
2.1 Attention Message ................................. 4
2.2 Sense Operation ................................... 5
2.3 Input Operation ................................... 5
2.3.1 Initialization ............................. 6
2.3.2 Input Phase ................................ 6
2.3.3 Termination ................................ 7
2.3.4 Input Operation Format ..................... 8
2.4 Output Operation .................................. 8
2.4.1 Initialization ............................. 8
2.4.2 Output Phase ............................... 9
2.4.3 Termination ................................ 9
2.4.4 Output Operation Format .................... 10
2.5 Other Operations .................................. 10
2.6 Printouts ......................................... 10

3. NETWORK INTERFACE ...................................... 13
3.1 NPM Operations .................................... 13
3.1.1 Open Operations ............................ 13
3.1.2 Receive Operations ......................... 13
3.1.3 Send Operations ............................ 14
3.1.4 Close Operations ........................... 15
3.2 SC Operations ..................................... 15
3.2.1 Event Control .............................. 15
3.2.1.1 Establish Request ................. 15
3.2.1.2 Removal Request ................... 16
3.2.1.3 Other Results ..................... 16
3.2.2 Connect Accept ............................. 17
3.2.3 Disconnect Accept .......................... 17
3.2.4 Abort Request .............................. 17
\f

T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _(_c_o_n_t_i_n_u_e_d_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_

3.3 VTP Operations .................................... 18
3.3.1 Connection and Disconnection of Terminals .. 18
3.3.2 Input ...................................... 19
3.3.2.1 Text Blocks ....................... 20
3.3.2.2 Ctrl Blcoks ....................... 20
3.3.2.3 Conn Blocks ....................... 20
3.3.2.4 Telegrams ......................... 21
3.3.3 Output ..................................... 21
3.3.3.1 Text Blocks ....................... 21
3.3.3.2 Ctrl Blocks ....................... 21
3.3.3.3 Conn Blocks ....................... 22
3.3.3.4 Telegrams ......................... 22

4. PROGRAM STRUCTURE ...................................... 23
4.1 Notation .......................................... 23
4.2 Normal Operation Flow ............................. 26
4.2.1 Message from an Application Process ........ 26
4.2.2 Input Answer from the Network .............. 27
4.3 Start and Stop of Operation Flow .................. 29
4.3.1 Start of Operation Flow .................... 29
4.3.2 Stop of Operation Flow ..................... 29
4.4 Structure of the Program Text ..................... 30

5. SEMAPHORES AND OPERATIONS .............................. 32
5.1 Semaphores ........................................ 32
5.1.1 Initialization of Semaphores ............... 33
5.2 Operations ........................................ 33
5.2.1 Operations Signalled to wait _answer _pool/
att _answer/input _answer .................... 33
5.2.2 Operations Signalled to wait _message ....... 34
5.2.3 Operations Signalled to start _input ........ 35
5.2.4 Operations Signalled to term _task .......... 35
5.2.5 Survey of Operations ....................... 39
\f

iii

T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _(_c_o_n_t_i_n_u_e_d_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_

6. COROUTINES ............................................. 40
6.1 Coroutine start _network _input ..................... 40
6.1.1 Strategy for Multibuffering in answers Zone 41
6.2 Coroutine network _input ........................... 42
6.3 Coroutine appl _message ............................ 44
6.4 Coroutine terminal ................................ 45
6.4.1 Outlines of the Automaton .................. 46
6.4.2 Survey of States, Actions and Derivation
Rules ...................................... 51
6.4.3 The Work of the Automaton .................. 53
6.4.3.1 Notes ............................. 53
6.4.3.2 Description of the Actions ........ 54
6.5 Manipulations of VTP Text Blocks .................. 59
6.5.1 Character Conversions ...................... 59
6.5.2 Format Transformations ..................... 61
6.6 Manipulations of Zones ............................ 63
6.6.1 Open of Zones .............................. 63
6.6.2 Prepare read _char .......................... 63
6.6.3 Prepare Zone Record ........................ 64
6.6.4 Prepare write/out _char ..................... 64
6.6.5 Close of Zones ............................. 65
6.6.6 Block Procedures ........................... 65
6.6.6.1 Block Procedure answer _input ...... 65
6.6.6.2 Block Procedure send _output ....... 66
6.6.6.3 Block Procedure write _text _seg .... 67

7. TEST AND DEBUG TOOLS ................................... 68
7.1 Testoutput ........................................ 68
7.1.1 User Records ............................... 69
7.1.2 Printing the Testoutput .................... 70
7.1.3 Block Procedure ............................ 70
7.2 Log Printout ...................................... 71
7.3 Trace of Messages and Answers ..................... 71
7.4 Pseudonet ......................................... 73
\f

T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _(_c_o_n_t_i_n_u_e_d_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_

7.4.1 Program Structure .......................... 74
7.4.2 Semaphores ................................. 75
7.4.2.1 Initialization of Semaphores ...... 75
7.4.3 Operations ................................. 76
7.4.3.1 Survey of Operations .............. 76
7.4.4 Coroutines ................................. 77
7.4.4.1 Coroutine npm _message ............. 77
7.4.4.2 Coroutine npm _answer .............. 78
7.4.5 Input Commands and Verification ............ 80
7.4.5.1 Input Syntax ...................... 80
7.4.5.2 Verification ...................... 83

8. PROGRAM EXECUTION ...................................... 85
8.1 Resource Demands .................................. 85
8.1.1 Size ....................................... 85
8.1.2 Buf ........................................ 86
8.1.3 Area ....................................... 86
8.2 Prerequisites ..................................... 87
8.3 Program Parameters ................................ 87
8.3.1 Survey of Program Parameters ............... 87
8.4 Program Start Up .................................. 89
8.5 Error Messages .................................... 90
8.5.1 Warnings ................................... 90
8.5.2 Alarms ..................................... 90
8.6 Program Close Down ................................ 93
8.7 System Generation ................................. 93

A_P_P_E_N_D_I_C_E_S_:

A. REFERENCES ............................................. 95

B. INDEX .................................................. 97
B.1 Survey of Figures ................................. 97
B.2 Survey of Examples ................................ 97
\f

F_ 1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_C_T_I_O_N_ 1,

This paper is the reference document for the RC8000 Scroll Mode
Mapping (SMM) module. The purpose of the SMM module is to convert
(i.e. map) the X.28 interface and the Virtual Terminal Protocol
(VTP) into the terminal process interface used on the RC822 stan-
dard terminal. The mapping is performed so that the applications,
operating systems etc. executed in the RC8000 may be accessed
from virtual terminals - connected to CENTERNET - without chan-
ging the RC8000 programs.

A software configuration where two virtual terminals are acces-
sing RC8000 processes is outlined in example 1.

Example 1: Virtual terminals connected as RC8000 terminals.
\f

The example shows that the virtual terminals can be either local
(1) or remote (2). But the most important aspects of the example
are that

1 terminal = 1 port = 1 pseudo process

and that one terminal may access a number of applications.

1_._1_ _ _ _ _ _ _ _S_t_r_u_c_t_u_r_e_ _o_f_ _t_h_i_s_ _M_a_n_u_a_l_ 1.1

The interface to the RC8000 apllications is described in chapter
2. The interface is explained so that use of the manual: RC8000
Terminal Process (ref. 1) is superfluous.

Chapter 3 resumes the use of the host interface, i.e. NPM, the
Session Control, SC, and the Virtual Terminal Protocol, VTP. The
interface to the terminal operator is also described.

The implementation of the SMM module is explained in chapter 4:
Program Structure, chapter 5: Semaphores and Operations and
chapter 6: Coroutines.

The tools for debugging and/or testing the program are described
in chapter 7.

Finally, chapter 8 defines how to start and stop the execution of
SMM. Error messages and alarms are described.

1_._2_ _ _ _ _ _ _ _N_o_t_e_s_ _o_n_ _N_o_t_a_t_i_o_n_ _a_n_d_ _T_e_r_m_i_n_o_l_o_g_y_ 1.2

Character values are given in the same way as in ref. 4. A
character value is defined by <column>/<row> referring to the IA5
Basic Code Table.

I.e. 2/0 corresponds to the character value 2*16 + 0 = 32 (= SP)
and 6/13 = 6*16 + 13 = 109 (= m).
\f

In general this description uses the term 'coroutine' as a short
of 'incarnation of a coroutine', but hopefully this will not
cause any confusion.

F_ 2_._ _ _ _ _ _ _ _ _R_C_8_0_0_0_ _T_E_R_M_I_N_A_L_ _P_R_O_C_E_S_S_ _I_N_T_E_R_F_A_C_E_ 2.

The SMM module has a terminal process interface to the applica-
tions in RC8000, i.e. the applications may access terminals con-
nected to CENTERNET as if they were ordinary RC822 terminals; see
ref. 1.

The communication takes place via pseudo processes named SMM1,
SMM2, ..., SMM50 (if <first> has the default value 1). The use of
pseudo processes has no effect on the use of SMM as terminal pro-
cess except that the process cannot be reserved.

The operations can be initiated by any internal process (no user-
check is performed). All operations are related to conversational
mode (mode = 0), i.e. ordinary roll mode.

On each terminal the operations are executed in the same order as
they are received, i.e. before executing the next operation the
current operation is answered.

2_._1_ _ _ _ _ _ _ _A_t_t_e_n_t_i_o_n_ _M_e_s_s_a_g_e_ 2.1

The operator can initialize an attention to an internal process
in different ways depending on the current state of the terminal
and on the purpose of the attention, see subsection 6.4.1.

Before the attention tasks are performed the current operation is
interrupted, if any.

The primitives ATT(1), PLEASE and EOM(2) will cause a printout of
the text

on the terminal and the operator is able to key the processname.
\f

The rules for converting input characters as described in subsec-
tion 2.3.2 apply also to the reading of the processname.

The processname may be empty, indicating current process.

If the process exists or if the primitive ATT(2) is entered, an
attention message is sent to the process via the corresponding
pseudo process with the following format:
message
+8 0
+10 0
+12 0
+14 0

If the application does not answer the attention message within
an optional time limit, the message is regretted.

The status word is not examined but the result of the answer must
be normal (i.e. = 1).

2_._2_ _ _ _ _ _ _ _S_e_n_s_e_ _O_p_e_r_a_t_i_o_n_ 2.2

The sense operation is dummy. The message is always answered with
status ok.

Format:
message answer
message/answer address: 0 0 status
+2: 0 number of halfwords
+4: 0 number of characters

2_._3_ _ _ _ _ _ _ _I_n_p_u_t_ _O_p_e_r_a_t_i_o_n_ 2.3

Input operations are accepted when the terminal is idle. Before
and during the negotiation phase, input operations are answered
with status disconnected.

2_._3_._1_ _ _ _ _ _I_n_i_t_i_a_l_i_z_a_t_i_o_n_ 2.3.1

When an input operation is accepted, the address of the sender is
compared with the process description address of the current pro-
cess. If the addresses are not equal the text

is sent to the terminal.

By means of an output message with 'your turn' indication - sent
by SMM - the bell is activated in the terminal and the operator
can enter data.

2_._3_._2_ _ _ _ _ _I_n_p_u_t_ _P_h_a_s_e_ 2.3.2

During the input phase TEXT-SEG primitives are transformed to one
text string stored in a local buffer with three 8-bit characters
per word. The characters are treated as 7-bit ISO characters
without parity. Provided that the conversion condition is true
the capital letters A through Z and the 3 national letters (e.g.
Æ, Ø, Å) (i.e. 4/1 through 5/13) are converted to the small let-
ters (i.e. 6/1 through 7/13). The characters (5/14) and
(7/14) are converted to NUL (0/0) no matter what the conversion
condition is. No control characters can appear in TEXT-SEG
primitives (i.e. 0/0 through 1/15).

The conversion condition is set to true when

- the terminal is connected at VTP protocol level
- the text 'att' has been written on the terminal
- an INTD is accepted.

The conversion condition is set to false when

- a small letter is received.

2_._3_._3_ _ _ _ _ _T_e_r_m_i_n_a_t_i_o_n_ 2.3.3

The input phase ends when the first primitive different from
TEXT-SEG is received.

If the primitive is either EOM(1) or EOM(2), an NL character
(0/10) is stored in the local buffer. Unused character positions
in the last word are filled with NUL characters. Provided that
the storage area within the application process defined by first
and last in the input message can hold the contents of the local
buffer, the input message is answered with status ok and a re-
ceipt is sent to the terminal (i.e. an output message with an NL
primitive). The input message is answered with status timer and
no bytes transferred if either the input message or the local
buffer in SMM (it can hold 150 characters) is too small. In this
situation the receipt is an output message with the text

<new line> last inputline skipped <new line>

If the primitive is either ATT(1), CLEAR or an illegal VTP primi-
tive, the situation is treated as if the input message is too
small.

If the primitive is ATT(2), the input message is answered with
status attention and no bytes transferred.

Any other input from the network will cause an answer with status
disconnected and no bytes transferred.

Note that the input operation cannot be terminated by a timer in-
terrupt.

2_._3_._4_ _ _ _ _ _I_n_p_u_t_ _O_p_e_r_a_t_i_o_n_ _F_o_r_m_a_t_ 2.3.4

message answer
message/answer address: 3<12+0 status
+2: first storage address number of halfwords
transferred
+4: last storage address number of charac-
ters transferred

Contents of possible status words:

0 ok
2 = 1<21 timer
7 = 1<16 attention
19 = 1< 4 disconnected

2_._4_ _ _ _ _ _ _ _O_u_t_p_u_t_ _O_p_e_r_a_t_i_o_n_ 2.4

Output operations are accepted when the terminal is idle. Before
and during the negotiation phase, output operations are answered
with status disconnected.

2_._4_._1_ _ _ _ _ _I_n_i_t_i_a_l_i_z_a_t_i_o_n_ 2.4.1

When an output operation is accepted, the address of the sender
is compared with the process description address of current pro-
cess. If the addresses are not equal, the text

is sent to the terminal.

2_._4_._2_ _ _ _ _ _O_u_t_p_u_t_ _P_h_a_s_e_ 2.4.2

During the output phase, the text string within the application
process, defined by first and last in the output message, is
transformed to NL and TEXT-SEG primitives. The primitives are
sent in one or more blocks to the terminal.

The text string must be packed with three 8-bit characters per
word. The characters are interpreted as 7-bit ISO characters
without parity.

The NL character (0/10) is sent as an NL primitive whereas the
text characters SP through å, except (i.e. 2/0 through 7/13
except 5/14) are sent without conversion in TEXT-SEG primitives.
All other characters are ignored. A sequence of text characters
is sent as one TEXT-SEG primitive. If the sequence consists of
more than 60 characters or if the network buffer is exhausted,
current TEXT-SEG primitive is terminated and a new one is initia-
lized.

2_._4_._3_ _ _ _ _ _T_e_r_m_i_n_a_t_i_o_n_ 2.4.3

Normally, the output phase ends when the text string is proces-
sed; in this case the output message is answered with status ok.

Between the blocks sent to the terminal, SMM may receive input
from the network. Depending on the type of these inputs, the out-
put message may be returned with various status words.

If SMM receives a TEXT-SEG primitive, an EOM(1) or an illegal VTP
primitive, the output message is answered with status ok, but
number of characters transferred may be less than the length of
the text string.

If SMM receives an interrupt (i.e. ATT(1), ATT(2), PLEASE,
EOM(2), CLEAR) the output message is answered with status atten-
tion; the number of characters transferred may be less than the
length of the text string.
\f

Any other input from the network will cause an answer with status
disconnected and no bytes transferred.

Note that the output operation cannot be terminated by a timer
interrupt.

2_._4_._4_ _ _ _ _ _O_u_t_p_u_t_ _O_p_e_r_a_t_i_o_n_ _F_o_r_m_a_t_ 2.4.4

message answer
message/answer address: 5<12+0 status
+2: first storage address number of halfwords
transferred
+4: last storage address number of charac-
ters transferred

Contents of possible status words:

0 ok
7 = 1<16 attention
19 = 1< 4 disconnected

2_._5_ _ _ _ _ _ _ _O_t_h_e_r_ _O_p_e_r_a_t_i_o_n_s_ 2.5

If SMM receives a message where the operation-mode word (i.e.
message address + 0) is different from 0 (sense), 3<12+0 (input)
and 5<12+0 (output), the message is returned with result 3 (i.e.
unintelligible). Note that the status word and the rest of the
answer are irrelevant.

2_._6_ _ _ _ _ _ _ _P_r_i_n_t_o_u_t_s_ 2.6

During communication, a number of printouts may be produced by
SMM. These printouts can either be of an informative nature or
they can indicate an illegal situation.
\f

The printouts have the same format as the output blocks produced
for output operations from an application.

The printouts are listed in alphabetical order and the informa-
tive printouts are marked with an asterisk (*).

* EOM(2) indicates that the application is
able to receive input; the turn is
changed in order to enable the
operator to enter data and the
bell is activated.

* <nl> receipt on an input operation im-
plying that the characters have
been forwarded to the application
or a process name has been
received.

* <nl> att indicates that a (new) processname
may be written on the terminal.

disconnected <nl> dummy answer (4) on an attention
message to the application.

does not exist<nl> dummy answer (5) on an attention
message to the application.

* <nl> from <processname><nl> is written if the succeeding data
is sent by another process than
latest active application.

illegal <nl> the processname is not the name of
an internal process.

<nl> last inputline skipped<nl>
The last input line has not been
forwarded to the application be-
cause it was longer than wanted by
the application or similar error.
\f

no answer <nl> the application did not answer the
attention message within a certain
(optional) time limit. The atten-
tion message has been regretted by
SMM.

rejected <nl> dummy answer (2) on an attention
message to the application.

* <nl> to <process name><nl> indicates that <process name> is
able to receive data. The text is
sent only if the former process was
different to <process name>.

unintelligible <nl> dummy answer (3) on an attention
message to the application.

unknown <nl> the process does not exist. The
name is either the one just typed
or current process name if the name
was omitted.

unnormal <nl> dummy answer (1); usually that
answer means normal answer but if
this error occurs, it denotes an
abnormal situation in SMM.
\f

F_ 3_._ _ _ _ _ _ _ _ _N_E_T_W_O_R_K_ _I_N_T_E_R_F_A_C_E_ 3.

All communication between SMM and the network take place via Net-
work Port Module (NPM), see ref. 3. SMM works on two protocol
levels, i.e. Session Control (SC) and Virtual Terminal Protocol
(VTP).

3_._1_ _ _ _ _ _ _ _N_P_M_ _O_p_e_r_a_t_i_o_n_s_ 3.1

All operations from SMM to the network are packed in SEND opera-
tions and all operations from the network to SMM are packed in
RECEIVE operations, with the only exception that SMM requests
open and close of ports by means of OPEN and CLOSE operations.
The format of the operations is described in ref. 3.

3_._1_._1_ _ _ _ _ _O_p_e_n_ _O_p_e_r_a_t_i_o_n_s_ 3.1.1

When a terminal coroutine is started or after a close of the
port, an open operation is sent to NPM.

The receivermask used in the open operation is optional with all-
ones as a default. The number of buffers is set to 2 plus number
of letters per terminal (optional) for receiving and 1 for sen-
ding. The bufferlength is 201 characters for receiving as well as
sending. The immediate acknowledge request for sending is not
used, i.e. R=0.

If the open was unsuccessful, the procedure is repeated after a
certain - optional - amount of time. The number of attempts is
unlimited.

3_._1_._2_ _ _ _ _ _R_e_c_e_i_v_e_ _O_p_e_r_a_t_i_o_n_s_ 3.1.2

The network is able to forward data only in case the receiver has
delivered a receive operation with the sc-function in question.
\f

In order to establish a session, SMM sends an event control to
NPM. When the SC connection is settled, SMM sends a telegram
operation and an optional number of letter operations. (The con-
nection on VTP level is requested by means of letters).

Whenever SMM accepts a receive operation, the contents are trans-
formed to local operations and a new receive operation with the
same sc-function is delivered to NPM. I.e. if a letter is recei-
ved from NPM, SMM sends a new receive operation fitted for a let-
ter to NPM. If a receive operation is provided with serious er-
rors, the operation is not repeated, and a local operation is
created which causes the removal of the connection and the clo-
sing of the port in question.

3_._1_._3_ _ _ _ _ _S_e_n_d_ _O_p_e_r_a_t_i_o_n_s_ 3.1.3

SMM outputs send operations to NPM for SC negotiation operations,
letters and telegrams.

The SC negotiation operations used are connect accept (CON-AC),
disconnect accept (DISCON-AC) and abort request (ABORT).

All operations at VTP level are forwarded by letters and tele-
grams. The letters are used for text blocks, control blocks and
negotiation phase commands while telegrams are used for inter-
rupts (i.e. the CLEAR primitive).

3_._1_._4_ _ _ _ _ _C_l_o_s_e_ _O_p_e_r_a_t_i_o_n_s_ 3.1.4

The close operation is used if SMM receives a status different
from OK from NPM or if the sc mode delivered in a receive oper-
ation contains an illegal sc function or if the sc result is not
OK. The status and result of the close operation is not inspected
and the execution of SMM continues, cf. subsection 3.1.1.

If the execution of SMM is stopped by the supervisor cf. section
8.6 or by a serious error in the program, close operations are
sent for each possible port (= terminal).

3_._2_ _ _ _ _ _ _ _S_C_ _O_p_e_r_a_t_i_o_n_s_ 3.2

The SC level is used for establishment, monitoring and removal of
sessions. Before a session can be established the port must be
open; SMM opens a port as described in subsection 3.1.1. Sessions
are monitored by means of the receive operation EVENT CONTROL
while the removal of sessions is achieved either by the send
operation ABORT or by the close operation (described in subsec-
tion 3.1.4).

Data transfer is done by RECEIVE and SEND operations as described
in subsections 3.1.2 and 3.1.3.

3_._2_._1_ _ _ _ _ _E_v_e_n_t_ _C_o_n_t_r_o_l_ 3.2.1

The event control is a receive operation which can give a number
of results.

3_._2_._1_._1_ _ _ _E_s_t_a_b_l_i_s_h_ _R_e_q_u_e_s_t_ 3.2.1.1

All sessions are initiated by SMT, i.e. SMM receives an establish
request as a result of an event control.
\f

The request is accepted if the terminal coroutine is in the state
just after open (i.e. port reserved) and the following tests are
fulfilled

- class = high (i.e. 2)
- protocol field = VTP identification (i.e. 251); this field
is the first character in the condata area
- VTP role = terminal role (i.e. 0); this field is the second
character in the condata area.

If the request is not accepted SMM aborts the session, if any.

3_._2_._1_._2_ _ _ _R_e_m_o_v_a_l_ _R_e_q_u_e_s_t_ 3.2.1.2

SMT sends a removal request when the operator enters the CLR
command. SMM accepts the disconnection in any state provided the
port is reserved.

The cause received in the operation is not examined. This removal
request at SC level is a disconnect at VTP level, too.

3_._2_._1_._3_ _ _ _O_t_h_e_r_ _R_e_s_u_l_t_s_ 3.2.1.3

If the result delivered from SC is abnormal termination, low
layer error or SC protocol error, the session is removed and SMM
accepts the operation and continues as just after an open of the
port.

But if the result modification is unknown or if the basic result
does not indicate that the function was processed succesfully,
SMM aborts the session.

3_._2_._2_ _ _ _ _ _C_o_n_n_e_c_t_ _A_c_c_e_p_t_ 3.2.2

If SMM accepts an establish request, a connect accept operation
(CON-AC) is sent to SC. Besides the VTP role, which is applica-
tion role (i.e. 1) the contents are the same as received in the
request.

3_._2_._3_ _ _ _ _ _D_i_s_c_o_n_n_e_c_t_ _A_c_c_e_p_t_ 3.2.3

If SMM accepts a removal request, a disconnect accept operation
(DISCON-AC) is sent to SC. The 'cause' field is used for inform-
ing SMT about the state of the terminal at SMM site, i.e.

cause explanation
0 = disconnect confirma- current state is after VTP connect,
tion i.e. datatransfer at VTP level.

166 = connect procedure current state is datatransfer, i.e.
error after SC connect but before VTP
connect.

176 = sc protocol error in any other state, i.e. no SC
connection.

3_._2_._4_ _ _ _ _ _A_b_o_r_t_ _R_e_q_u_e_s_t_ 3.2.4

The abort request operation is used whenever SMM discovers a pro-
tocol error at the SC level or an error during the clear mecha-
nism or in the negotiation phase at VTP level. The operation con-
tains information about the cause of requiring the abnormal ter-
mination:

cause explanation
164 = clear procedure one of the symbols CELAR and CLEAR
error mark appears in an illegal context.
\f

cause explanation
166 = connect procedure VTP symbols before VTP connection
error is negotiated.

170 = unexpected vtp VTP connect request received but
connect the terminal is not in data trans-
fer state.

176 = sc procol error error in an SC operation or an
establish request when a session is
already established.

244 = parameters not errors in the parameters for a VTP
acceptable connection.

3_._3_ _ _ _ _ _ _ _V_T_P_ _O_p_e_r_a_t_i_o_n_s_ 3.3

The VTP protocol is based on the X.28 interface, see ref. 4,
and is implemented by means of letters and telegrams. The defini-
tion of the VTP protocol is given in ref. 5.

The protocol operates with two partners, the terminal and the
application. In this case the terminal role is played by the SMT
terminal (operator) and the application role is played by the SMM
terminal coroutine. This means that SMM has the tour after the
negotiation phase and after the execution of a clear mechanism.
SMM keeps the tour until input from the terminal operator is
required, i.e. SMM gives the tour to the terminal when an input
message is received from the application process or when the ope-
rator wants to contact another process by means of an attention.
When the operator completes the input, the tour is returned to
SMM.

3_._3_._1_ _ _ _ _ _C_o_n_n_e_c_t_i_o_n_ _a_n_d_ _D_i_s_c_o_n_n_e_c_t_i_o_n_ _o_f_ _T_e_r_m_i_n_a_l_s_ 3.3.1

Any connection at VTP level is initiated by the SMT. The connec-
tion is accepted if the terminal coroutine is in the state just\f

after SC connection (i.e. data transfer) and the following tests
are fulfilled

- protocol field = VTP identification (i.e. 251)
- maximum 7 parameters
- terminal mode = scroll mode (i.e. paramter 0)
- if any other parameter than terminal mode is stated the
range must allow the default value.

SMM accepts a connection by sending a connect accept command
(CACC) with the same parameters as received. The parameter values
returned to SMT are the default values except for the parameters:

terminal mode: is always scroll mode
line discrete: is the greatest value suggested in the range
given in the VTP connect request.

The extension field is zero.

The VTP command for disconnection is never used, instead one of
the SC operations disconnect request (removal request), abort
request (abnormal termination) and close is activated.

3_._3_._2_ _ _ _ _ _I_n_p_u_t_ 3.3.2

Input operations are either letters or telegrams. The contents of
letters must be structured as follows:

transport header = 1:
text block:
EOM indicator
TEXT-SEG primitives
control block:
please primitive/clear mark primitive
transport header = 2:
conn block
\f

Letters with other primitives, block indicators, transport
headers or which in other ways neglect the structure, are
transformed to illegal _vtp operations.

3_._3_._2_._1_ _ _ _T_e_x_t_ _B_l_o_c_k_s_ 3.3.2.1

One text block contains one EOM indicator and a number of TEXT-
SEG primitives. Each TEXT-SEG primitive is transformed to an in-
ternal operation, if the number of data characters in the TEXT-
SEG primitive is greater than a certain value (p.t. 81 charac-
ters) the primitive is divided into a number of internal oper-
ations with at most 81 characters each.

When all the TEXT-SEG primitives in the text block have been pro-
cessed succesfully, the EOM indicator is examined. If the EOM
indicator is zero, no more operations are produced, but if it
equals 1, an eom operation is produced and any other value of the
EOM indicator will result in an eom _att _1 operation.

3_._3_._2_._2_ _ _ _C_t_r_l_ _B_l_o_c_k_s_ 3.3.2.2

One ctrl block must hold exactly one primitive which can be
either a please primitive or a clear mark primitive.

3_._3_._2_._3_ _ _ _C_o_n_n_ _B_l_o_c_k_s_ 3.3.2.3

The conn blocks are examined as described in subsection 3.3.1. If
the contents are acceptable, a vtp _conn _accp operation is
produced. Otherwise a vtp _conn _not _accp is produced.

3_._3_._2_._4_ _ _ _T_e_l_e_g_r_a_m_s_ 3.3.2.4

A telegram holds one telegram byte and SMM accepts the following
values:

telegram byte internal operation
1 att _1
2 att _2
15 att _15
16 clear

An illegal telegram byte will give an illegal _vtp operation.

3_._3_._3_ _ _ _ _ _O_u_t_p_u_t_ 3.3.3

Output operations are produced either because of the protocol,
reception of application messages or errors. The operations are
sent in letters and telegrams.

The formats of the operations are described in ref. 5 and 6.

3_._3_._3_._1_ _ _ _T_e_x_t_ _B_l_o_c_k_s_ 3.3.3.1

Each text block contains one EOM indicator and a number of TEXT-
SEG and NL primitives.

The EOM indicator is either zero (i.e. my turn) or it is 2 (i.e.
your turn).

3_._3_._3_._2_ _ _ _C_t_r_l_ _B_l_o_c_k_s_ 3.3.3.2

SMM produces only one kind of ctrl blocks and that is clear mark
ctrl block.

3_._3_._3_._3_ _ _ _C_o_n_n_ _B_l_o_c_k_s_ 3.3.3.3

As described in subsection 3.3.1 SMM produces cacc blocks, and no
other conn blocks are sent.

3_._3_._3_._4_ _ _ _T_e_l_e_g_r_a_m_s_ 3.3.3.4

Attention from SMM to the terminal does not exist, so the only
telegram sent is clear (telegram byte = 16).

F_ 4_._ _ _ _ _ _ _ _ _P_R_O_G_R_A_M_ _S_T_R_U_C_T_U_R_E_ 4.

The SMM program consists of a number of coroutines communicating
by means of operations which are signalled to or waited from se-
maphores.

The external communication is implemented by messages and
answers.

The control and monitoring of coroutines, operations and sema-
phores are performed by a coroutine system, see ref. 7, which
offers standard procedures for signal and wait of operations and
a centrallogic which performs the scheduling and which transforms
(some of) the external messages and answers to internal opera-
tions.

4_._1_ _ _ _ _ _ _ _N_o_t_a_t_i_o_n_ 4.1

user semaphore with a name and an
name identification number (no)
(no)

group of user semaphores with the
M_M_ name same name and function but with
P_P_
different identification numbers
M_M_ (no ,..., no )
P_P_ 1 n

standard semaphore defined by the
coroutine system

signal an operation to a semaphore

wait for an operation from a
semaphore
\f

coroutine with a name and an ident-
name ification number (no)
(no)

incarnations of a coroutine with
name one name and a number of different
M_M_ (no ,..., no ) identification numbers
P_P_ 1 n
M_M_ (no ,..., no )
P_P_ 1 n

message and corresponding answer
message
answer

transformation of an input oper-
ation to an output operation per-
formed by a coroutine by means of:
wait operation
<execute task>
signal operation

*) one operation results in two oper-
ations/messages/answers

*) two operations/messages/answers re-
sult in one operation

*) if the paths are disjointed, it in-
dicates a choice
\f

Figure 1: Normal operation flow.
\f

F_ 4_._2_ _ _ _ _ _ _ _N_o_r_m_a_l_ _O_p_e_r_a_t_i_o_n_ _F_l_o_w_ 4.2

The diagram in fig. 1 shows the flow of the operations during
normal operation, i.e. when a session is active (=connected).

For each terminal the flow can be activated either when SMM re-
ceives a message form an application process or when SMM receives
an answer from the network concerning an input message.

4_._2_._1_ _ _ _ _ _M_e_s_s_a_g_e_ _f_r_o_m_ _a_n_ _A_p_p_l_i_c_a_t_i_o_n_ _P_r_o_c_e_s_s_ 4.2.1

When SMM receives a message from an application process, the cen-
trallogic waits for an operation on the wait _message _pool sema-
phore and signals the operation to the wait _message semaphore.

The appl _message coroutine applied for the pseudo process, which
has received the message, is started. After processing this ope-
ration, the appl _message coroutine signals the operation to the
term _task applying to the same pseudo process.

The terminal coroutine processes the operation, i.e. converts the
output message to an internal operation, prints 'from' or 'to' on
the terminal, sends a 'your turn' indication to SMT, tranforms an
output buffer to a network operation and answers the application-
message, etc.

If the operation is an output operation which could not be com-
pleted in one output message, the operation is returned to the
terminal _task semaphore.

If the operation implies output to the network, the terminal co-
routine sends an output message and awaits the answer before the
process proceeds.

When an operation is completed by the terminal coroutine, the
operation is returned to wait _message _pool semaphore.

4_._2_._2_ _ _ _ _ _I_n_p_u_t_ _A_n_s_w_e_r_ _f_r_o_m_ _t_h_e_ _N_e_t_w_o_r_k_ 4.2.2

When SMM receives an answer on an input message from the network,
the centrallogic examines the wait _answer _pool semaphore for an
operation with the same message buffer address. This operation is
signalled to the semaphore indicated in the operation, i.e.
input _answer semaphore.

The network _input coroutine waits for the operations on the
input _answer semaphore. The input answer is transformed to an
internal operation, the resource for this operation is required
either from the small _pool or from the large _pool semaphore de-
pending on the type of the input. The internal operation is sig-
nalled to the terminal _task specified in the operation received
from input _answer semaphore. After processing the input answer, a
new input message is sent to the network and the original opera-
tion is returned to the wait _answer _pool semaphore.

The terminal coroutine applied for the port in question receives
the operation from the terminal _task semaphore and processes it,
i.e. converts the input characters to a text string, answers an
application message with the converted input line, sends an at-
tention message to an application process, aborts current ses-
sion, etc.

If the process implies an attention message to an application,
the terminal coroutine waits for the message _pool semaphore for a
free operation, which is signalled to the wait _answer _pool sema-
phore with the actual message buffer address of the attention
message sent. When the application has answered the attention
message, the centrallogic returns the operation from the
wait _answer _pool for the att _answer sempahore. Now the terminal
coroutine receives the operation and continues by returning it to
the message _pool semaphore.

Figure 2: Start and stop of operation flow.
\f

F_ 4_._3_ _ _ _ _ _ _ _S_t_a_r_t_ _a_n_d_ _S_t_o_p_ _o_f_ _O_p_e_r_a_t_i_o_n_ _F_l_o_w_ 4.3

The diagram in fig. 2 shows how the operation flow is started and
how it is stopped.

4_._3_._1_ _ _ _ _ _S_t_a_r_t_ _o_f_ _O_p_e_r_a_t_i_o_n_ _F_l_o_w_ 4.3.1

After a successful open of a port, the terminal coroutine gets a
free operation from the small _pool semaphore and signals it to
the start _input semaphore. The coroutine start _network _input
waits for operations on the start _input semaphore and when it
gets one it sends one or more input messages to the network and
returns the operation to the small _pool semaphore.

4_._3_._2_ _ _ _ _ _S_t_o_p_ _o_f_ _O_p_e_r_a_t_i_o_n_ _F_l_o_w_ 4.3.2

When the network input coroutine receives an input answer ope-
ration with status not OK or other unacceptable results/contents,
the operation is returned to the message _pool semaphore and the
input message is not repeated.

In order to inform the terminal coroutine, the network _input
coroutine gets a free operation from the small _pool semaphore and
signals it to the terminal _task; this operation will move the
terminal coroutine to send a close port message to the network.
Finally the operation is released to the small _pool semaphore,
again.

4_._4_ _ _ _ _ _ _ _S_t_r_u_c_t_u_r_e_ _o_f_ _t_h_e_ _P_r_o_g_r_a_m_ _T_e_x_t_ 4.4

The program consists of a number of blocks; the most important of
the blocks are

first declaration block
initialize program options
second declaration block

initialize actions and states
initialize text strings and conversion tables
coroutines
initialize coroutine system
trap routine.

The structure of these blocks and the details concerning
declaration of variables and procedures are shown in fig. 3.
\f

F_ begin
release identification
begin <_*_ _f_i_r_s_t_ _d_e_c_l_a_r_a_t_i_o_n_ _b_l_o_c_k_ _ _ _ _*_>_
declarations (alphabetical order per type)
begin <_*_ _i_n_i_t_i_a_l_i_z_e_ _p_r_o_g_r_a_m_ _o_p_t_i_o_n_s_ _*_>_
declarations
procedure get _param
initialize program options
end
initialize constants
begin <_*_ _s_e_c_o_n_d_ _d_e_c_l_a_r_a_t_i_o_n_ _b_l_o_c_k_ _ _ _*_>_
declarations (alphabetical order per type)
procedure test _error
trace _message
trace _answer
trace _buffer
monitor _send _answer
monitor _send _message
initialize arrays
begin <_*_ _a_c_t_i_o_n_s_ _a_n_d_ _s_t_a_t_e_s_ _ _ _ _ _ _ _ _ _*_>_
procedure table
initialize tables
end
begin <_*_ _t_e_x_t_ _s_t_r_i_n_g_s_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _*_>_
declarations
procedure write _text
copy _string
initialize text strings
end
initialize conversion tables
initialize zones
begin <_*_ _c_o_r_o_u_t_i_n_e_ _p_r_o_c_e_d_u_r_e_s_ _ _ _ _ _ _ _*_>_
procedure terminal
start _network _input
prepare _upon _input (no coroutine)
network _input
appl _message
npm _message (pseudonet)
answer _npm _message (pseudonet)
npm _answer (pseudonet)
initialize the coroutine system
close _all _ports: <_*_ _t_r_a_p_ _r_o_u_t_i_n_e_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _*_>_
trap routine
end coroutine block
end second declaration block
end first declaration block
end program

Figure 3: Structure of the program text.
\f

F_ 5_._ _ _ _ _ _ _ _ _S_E_M_A_P_H_O_R_E_S_ _A_N_D_ _O_P_E_R_A_T_I_O_N_S_ 5.

5_._1_ _ _ _ _ _ _ _S_e_m_a_p_h_o_r_e_s_ 5.1

There are two groups of semaphores, standard (pre-defined)
semaphores and user defined semaphores. Each semaphore is
identified by a number.

SMM uses the standard semaphores

delay (-3)
wait _answer _pool (-2)
wait _message (-1)
wait _message _pool (0).

The standard semaphores are described in ref. 7.

The user defined semaphores are

large _pool (1)
message _pool (2) semaphores for free operations of
small _pool (3) different lengths
input _answer (4) used for receiving answers on input
messages to the network
att _answer (5) used for receiving answers on
attention messages to
application processes
start _input (6) used for initiating input messages
to the network
terminal _task (11,12...,10 + terms)
each semaphore holds the operations
(tasks) for a specific terminal
(i.e. port or pseudo process).

5_._1_._1_ _ _ _ _ _I_n_i_t_i_a_l_i_z_a_t_i_o_n_ _o_f_ _S_e_m_a_p_h_o_r_e_s_ 5.1.1

Before the coroutine system is started, the semaphores are init-
ialized with a number of operations of a specific size:

semaphore operation number of operations
size (HW) per terminal
wait _message _pool 22 1
large _pool 168 1 + <letters per term>
message _pool 22 1 + <inputs per term>
small _pool 8 2 + <inputs per term>.

5_._2_ _ _ _ _ _ _ _O_p_e_r_a_t_i_o_n_s_ 5.2

Each operation is received by a coroutine from a semaphore by
means of the standard procedure wait and after use it is returned
to a semaphore by means of the standard procedure signal.

This description will define the contents of the operations sig-
nalled to each semaphore. The semaphores delay,
wait _message _pool, large _pool, message _pool and small _pool will
never hold operations with defined contents.

M_M_m_m_5.2.1 Operations Signalled to wait _answer _pool/att _answer/input _answer 5.2.1
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

The centrallogic requires that the second field is the message
buffer address and that the third field is the identification of
the answer semaphore where the operation is returned when the
answer is received. The rest of the fields in the operation are
not used by the centrallogic but when SMM signals an operation to
wait _answer _pool, some of the free fields may hold information.

When the answer semaphore is att _answer the operation format is

field type name
1 i -
2 i message _addr
3 i answer _semaphore = att _answer.
\f

When the answer semaphore is input _answer the operation format is

field type name
1 i terminal _semaphore
2 i message _addr
3 i answer _semaphore = input _answer
4 i share _no
5 i first _shared.

The centrallogic returns the operation - unchanged - to the
answer semaphore when the answer for the specified message buffer
is received.

M_M_m_m_5.2.2 Operations Signalled to wait _message 5.2.2
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

The centrallogic signals to the wait _message semaphore when it
receives a message. The operation has the following format

field type name
1 i (sender)
2 i (receiver)
3 i buffer = message buffer address
4 ia message _area

where the format of the message _area array is

field type name
1 i operation _mode
2 i first
3 i last
4 i start _relative or port _address
5 i sc _mode.

M_M_m_m_ 5.2.3 Operations Signalled to start _input 5.2.3
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

There is one kind of operations on the start _input semaphore,
i.e.

field type name
1 i current _term _task
2 i protocol _state.

Current _term _task is the identification of the term _task sema-
phore connected to the terminal coroutine which is going to be
started.

The field protocol _state indicates which kind of input (receive)
message the start _network _input coroutine shall send to the net-
work:

protocol _state = 1: after open: send one event control
= 2: after sc connect: send one receive
telegram and <letters per term> receive
letter(s).

M_M_m_m_5.2.4 Operations Signalled to term _task 5.2.4
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

The name term _task is used on the semaphores connected to the
terminal coroutine incarnations; each incarnation owns one
semaphore.

All operations signalled to term _task have an operation code in
the first field

field type name
1 i op _code = typegroup < 6 + symbol
\f

The operation code divides the operations into groups of types:

typegroup value contents
a 1 SC operations and NPM operations
b 2 VTP operations from ctrl block, conn
blocks and telegrams; and illegal VTP
operations
c 3 VTP operations form text blocks
d 4 application messages
e 5 internal operations concerning
application outputs.

The values of symbol are independent of the typegroup. In the
rest of this subsection, the contents of the operations are de-
scribed (in numerical order of symbol); note that the contents of
undescribed fields are not defined.

Name: sc _conn; typegroup = a, symbol = 1

field type name
3 i length
4 ia data

where data (index) is the integer number index received as a
connect request result of an event control.

Name: sc _disc; typegroup = a, symbol = 2

no fields.

Name: sc _abort; typegroup = a, symbol = 3

field type name
3 i cause.

Name: ts _close; typegroup = a, symbol = 4
sc _error; typegroup = a, symbol = 5

no fields.

Name: abnormal _answer; typegroup = a, symbol = 6

field type name
3 i answer _result.

Name: illegal _status; typegroup = a, symbol = 7

field type name
3 i rec _status

where rec _status either contains the status word or the result
received from NPM. If both the result and the status word was
acceptable, the field contains the value of the sc _mode field
(indicated by its negative value).

Name: att _1 ; typegroup = b, symbol = 8
att _2 ; typegroup = b, symbol = 9
att _15 ; typegroup = b, symbol = 10
clear ; typegroup = b, symbol = 11
please ; typegroup = b, symbol = 12
clear _mark ; typegroup = b, symbol = 13

no fields.

Name: vtp _conn _accp; typegroup = b, symbol = 14

field type name
3 i counter
4 ia parameters

where each parameter is described as follows
parameters (index*2 - 1) = parameter identification number
parameters (index*2) = accepted value of parameter.

Name: vtp _conn _not _accp; typegroup = b, symbol = 15
illegal _vtp ; typegroup = b, symbol = 16

no fields.

Name: text _portion; typegroup = c, symbol = 17

field type name
3 i length
4 ia data

where data(index) is the value of the character number index.

Name: eom ; typegroup = c, symbol = 18
eom _att _1 ; typegroup = c, symbol = 19

no fields.

Name: sense _message ; typegroup = d, symbol = 20
input _message ; typegroup = d, symbol = 21
output _message ; typegroup = d, symbol = 22
illegal _message; typegroup = d, symbol = 23

field type name
2 i sender
3 i buffer
4 ia message _area (see subsection 5.2.2).

Name: output _portion; typegroup = e, symbol = 24

field type name
2 i sender
3 i buffer
4 ia message _area

and message _area.start _relative >_ 0 indicating the index of the
first halfword to be processed.

5_._2_._5_ _ _ _ _ _S_u_r_v_e_y_ _o_f_ _O_p_e_r_a_t_i_o_n_s_ 5.2.5

semaphore
name generated by source destination

answer _op, before network _input/ input _answer wait _answer _pool
start _network _input message _pool wait _answer _pool
answer _op, after centralogic wait _answer _pool (def. in field 3)
message _op, before terminal terminal _task wait _message _pool
message _op, after centralogic wait _message _pool wait _message
start _input terminal small _pool start _input
sc _conn network _input large _pool terminal _task
sc _disc network _input small _pool terminal _task
sc _abort network _input small _pool terminal _task
ts _close network _input small _pool terminal _task
sc _error network _input small _pool terminal _task
abnormal _answer network _input small _pool terminal _task
illegal _status network _input small _pool terminal _task
att _1 network _input small _pool terminal _task
att _2 network _input small _pool terminal _task
att _15 network _input small _pool terminal _task
clear network _input small _pool terminal _task
please network _input small _pool terminal _task
clear _mark network _input small _pool terminal _task
vtp _conn _accp network _input large _pool terminal _task
vtp _conn _not _accp network _input small _pool terminal _task
illegal _vtp network _input small _pool terminal _task
text _portion network _input large _pool terminal _task
eom network _input small _pool terminal _task
eom _att _1 network _input small _pool terminal _task
sense _message appl _message wait _message terminal _task
input _message appl _message wait _message terminal _task
output _message appl _message wait _message terminal _task
illegal _message appl _message wait _message terminal _task
output _portion terminal terminal _task terminal _task

Note that the coroutines, terminal and appl _message, exist in one
incarnation per terminal and that each terminal has one terminal _
task semaphore. All operations on a terminal _task semaphore con-
cern only the terminal that owns the semaphore.
\f

F_ 6_._ _ _ _ _ _ _ _ _C_O_R_O_U_T_I_N_E_S_ 6.

The coroutines are implemented as procedures and the incarnations
are started by means of the ALGOL8 procedure new _activity. Each
incarnation is identified by a number. When an incarnation of a
coroutine is started, the parameters for the procedure are
stated. The coroutines all have the same priority, i.e. zero.

The coroutines are

name identification
start _network _input 1
network _input 2
appl _message 3, 5, ..., 1 + terms*2
terminal 4, 6, ..., 2 + terms*2

The identifications indicate that start _network _input and
network _input have only one incarnation while appl _message and
terminal have one incarnation per terminal.

M_M_m_m_6.1 Coroutine start _network _input 6.1
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

The start _network _input coroutine initiates the receiving of
inputs from the network depending on the protocol state of the
terminal in question.

Pseudo code:

procedure start _network _input;
repeat
wait (start _input, start _op);
if start _op. protocol _state = after sc connect then
send receive letter <letters per term>-times
send receive telegram
else
send event control
signal (small _pool, start _op);
until false;

6_._1_._1_ _ _ _ _ _S_t_r_a_t_e_g_y_ _f_o_r_ _M_u_l_t_i_b_u_f_f_e_r_i_n_g_ _i_n_ _a_n_s_w_e_r_s_ _Z_o_n_e_ 6.1.1

The zone named answers has one share per possible input (receive)
message sent to the network (i.e. NPM) plus one for the trap
routine. Each terminal may have one event control, one receive
telegram and <letters per term> receive letter(s) input messages
sent to the network.

Each share is dedicated for one purpose connected to a specific
terminal. The shares for one terminal are consecutive:

shareno purpose
i + 1 first receive letter
M_M_ . .
. .
P_P_ . .
i + <letters per term> last receive letter
i + <letters per term> + 1 receive telegram
i + <letters per term> + 2 event control

The shares for the whole system are grouped as follows:

shares for the first terminal
shares for the second terminal
M_M_ .
.
P_P_ .
shares for the last terminal
one share for the trap routine (for closing ports)

M_M_m_m_6.2 Coroutine network _input 6.2
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

The network _input coroutine receives the answers on the input
messages sent to the network.

The coroutine transforms an answer to one or more internal oper-
ations which are signalled to the associated terminal _task sema-
phore. If the answer was acceptable, i.e. status was OK, result
was normal, sc-result was OK and the contents of the data buffer
were legal, a new input message with the same sc function is sent
to the network. If the answer was unacceptable, the input is not
repeated.

A description of the tests on the contents of the data buffer can
be found in the sections 3.2 and 3.3.

F_ Pseudocode:

procedure network _input;
repeat
wait (input _answer, answer _op);
wait _message (answer _op. share _no, answer);
if result is not ok or status is not ok then
create abnormal _answer or illegal _status operation
signal (message _pool, answer _op);
else
if sc _function = receive _letter and sc _result is ok then
text block: create one or more text _portion operations
create eom or eom _att _1 operation, if necessary
ctrl block: create please or clear _mark operation
conn block: create vtp _conn _accp or vtp _conn _not _accp operation
if any errors during examination of input then
cancel the created operations, if possible
create illegal _vtp operation
else
if sc _function = event _control then
establish _request: create sc _conn operation
removal _request: create sc _disc operation
abnormal _termination: create sc _abort operation
sc _low _layer _error: create sc _close operation
sc _protocol _error: create sc _close operation
if any errors during examination of input then
cancel the created operation
create sc _error operation
else
if sc _function = receive _telegram and sc _result is ok then
create att _1, att _2, att _15, clear or illegal _vtp operation
else
create illegal _status operation
signal (message _pool, answer _op); goto end;

send new input message with the same sc _function
signal (wait _answer _pool, answer _op);
end:
until false;

Note that 'create --- operation' means wait for a free operation
from the associated pool semaphore, generate the contents of the
operation and signal the operation the terminal _task semaphore
specified in answer _op.
\f

M_M_m_m_ 6.3 Coroutine appl _message 6.3
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

The appl _message coroutine receives all the messages sent to a
specific pseudo process. The messages are transformed to internal
operations, which are signalled to the associated terminal _task
semaphore.

Pseudo code:

procedure appl _message (pseudo _process, term _task);
repeat
wait _select: = pseudo _process;
wait (wait _message, message _op);
create sense _message, input _message, output _message
or illegal _message operation (in message _op)
signal (term _task, message _op);
until false;

6_._4_ _ _ _ _ _ _ _C_o_r_o_u_t_i_n_e_ _t_e_r_m_i_n_a_l_ 6.4

The terminal coroutine performs the tasks signalled to the
associated terminal _task semaphore. The execution of the tasks is
controlled by a kind of a finite automaton with states, actions
and derivation rules (i.e. rules for the next state based on cur-
rent state and current input symbol). When a task is completed,
the operation as signalled to one of the pool semaphores (i.e.
small _pool, large _pool, wait _message _pool).

Pseudo code:

procedure terminal (term _task, pseudo _process);
initialization
repeat
wait _select: = select (cur _state);
wait _time: = time (cur _state);
wait (term _task, operation);
action: = actions (cur _state, operation.symbol);
new _state: = status (cur _state, operation.symbol);
perform (action);
if operation is not returned already then
semaphore: = return _to (operation.symbol);
signal (semaphore, operation);
cur _state: = new _state;
until false;

6_._4_._1_._ _ _ _ _O_u_t_l_i_n_e_s_ _o_f_ _t_h_e_ _A_u_t_o_m_a_t_o_n_ 6.4.1

The principles for the work of the finite automaton can be
outlined in three stages

- start, connect and stop the terminal
- normal work
- clear mechanism.

The notation used in the outlines are

symbol C
state action (no) D state
name name
(no) (no)

A B

which means that when the automaton (i.e. the terminal coroutine)
is in state A (identified by no) and receives a symbol (i.e. an
operation from terminal _task semaphore), C, it will perform the
action, D, and change the state to B. When C is 'no operation
received', it means that the queue of operations (semaphore
terminal _task) is empty; when D is denoted by a minus (-) it
means that no action is performed.
\f

The start, connect and stop of the terminal deal mainly with SC
level of communication, but serious errors at VTP level will
force the automaton into this level. See fig. 4.

Figure 4: Outline of start, connect and stop a terminal.
\f

The normal work of the terminal tasks takes place at VTP level.
Errors during the work will either start the clear mechanism or
bring it to SC level by means of an abort operation. See fig. 5.

Remarks to the figure:

- the symbols att _15 and please are ignored in states where they
are not mentioned.

- the symbol illegal _vtp will start the clear mechanism in any
state.

- the symbols att _1, att _2, text _portion, eom and eom _att _1 will
cause the start of the clear mechanism if they occur in a state
where they are not described.

- before leaving this part of the automaton caused by an error or
by a symbol from the SC level, the situation is neutralized,
i.e. the application message is answered, working zones are
closed and the like.
\f

Figure 5: Outline of the normal work of a terminal.
\f

F_ The clear mechanism works at VTP level. It may be started either
by the SMT terminal by means of a clear telegram or by an
erroneous situation in the automaton (i.e. unaccepted symbol in
current state). See fig. 6 and note that

- the vtp symbols are blind in all clear states.

- if the symbols clear and clear _mark occur in a state where they
are not mentioned they will interrupt the VTP protocol, i.e.
abort the session at SC level and the automaton continues in
the error state.

Figure 6: Outline of clear mechanism.
\f

F_ 6_._4_._2_ _ _ _ _ _S_u_r_v_e_y_ _o_f_ _S_t_a_t_e_s_,_ _A_c_t_i_o_n_s_ _a_n_d_ _D_e_r_i_v_a_t_i_o_n_ _R_u_l_e_s_ 6.4.2

The automaton is implemented by the tables states and actions,
which contain the derivation rules and the associated semantic
rules (i.e. the action to be taken).

Fig. 7 shows the contents of the tables.

Figure 7: Survey of the automaton.
Each entry denotes <action>/<next state>, a question
mark (?) means undefined and a minus (-) means either
no action or same state.

The states are identified by a number; fig. 7 gives a survey of
the states and their names. The actions are also identified by a
number. Some of the actions are composed by other actions. Fig. 8
gives a survey of the actions and their names.
\f

F_ Ident Name Note

1 send _open _port
2 answer _sc _connect
3 send _vtp _cacc
4 answer _appl _disconnected
5 write _att
6 convert _appl _name
7 search _process
8 close _help
9 send _att _message
10 send _att _message _reserved
11 answer _sense _message
12 prepare _input
13 receive _and _convert _input
14 finish _input
15 finish _input _and _write _att = #14 + #5
16 finish _input _after _error
17 finish _input _after _error _and _write _att = #16 + #5
18 answer _input _att _reserved _and _clear
19 answer _input _0 _bytes
20 answer _input _disconnected
21 answer _input _and _clear = #19 + #37
22 answer _input _and _abort = #20 + #45
23 answer _input _and _disconnect = #20 + #51
24 answer _input _and _close _port = #20 + #52
25 prepare _output
26 convert _and _send _output
27 answer _output _ok
28 answer _output _att = #30 + #5
29 answer _output _att _reserved = #30 + #9
30 answer _output _att _2
31 answer _output _ok _and _clear = #27 + #37
32 answer _output _att _and _clear = #30 + #37
33 answer _output _disconnected
34 answer _output _and _abort = #33 + #45
35 answer _output _and _disconnect = #33 + #51
36 answer _output _and _close _port = #33 + #52
37 send _clear
38 send _clear _mark
39 answer _illegal _message
40 answer _illegal _message _and _pass = #39 + #46
41 close _help _and _abort = #8 + #45
42 close _help _and _clear = #8 + #37
43 close _help _and _disconnect = #8 + #51
44 close _help _and _close _port = #8 + #52
45 abort
46 pass
47 answer _sense _message _and _pass = #11 + #46
48 answer _appl _disconnected _and _pass = #4 + #46
49 no _operation _received
50 no _action
51 disconnect
52 send _close _port
53 fatal

Figure 8: Survey of actions.
\f

F_ 6_._4_._3_ _ _ _ _ _T_h_e_ _W_o_r_k_ _o_f_ _t_h_e_ _A_u_t_o_m_a_t_o_n_ 6.4.3

The work of the automaton takes place in steps, with one step per
input symbol (as can be seen in the pseudo code, in the beginning
of this chapter). The work is controlled by the derivation rules
and the actions as described in subsection 6.4.2, but some notes
would be useful together with a description of the actions.

6_._4_._3_._1_ _ _ _N_o_t_e_s_ 6.4.3.1

Before a call of the coroutine procedure wait, it is possible to
specify a selection mask and a timer. In this case the selection
mask is used on the typegroup of the symbols in order to exclude
certain types of operations from being received in some states.
The timer is used with negative value in order to examine the
semaphore without being stopped if the queue is empty; this fa-
cility is used when it is necessary to clear the queue of oper-
ations before the work may continue. The values of wait _select
and wait _time can be seen in fig. 7.

Because of the selection of operations, a number of entries in
the tables, states and actions, are undefined. If one of these
entries is entered, the program is stopped by a run time alarm.

Sense messages from an application are always answered with
status OK no matter what the state is. Illegal messages are al-
ways answered with result unintelligible. Input and output mes-
sages are returned with status disconnected if they are received
before the idle state or in the port _closed state. An output mes-
sage operation is transformed to an internal output _portion oper-
ation in order to control the pointer (start _relative) in the
buffer when more than one send operation is required during the
conversion. If the output _portion operation is received in other
states than sending _output, it is treated as if it was an
ordinary output message.
\f

When an abort operation is sent to the network, the state is
changed either to port _reserved or to error. Port _reserved is
used if it happens before the idle state and error is used if it
happens in or after the idle state.

Whenever an output (= send) message is sent to the network, the
answer is examined and if it is not correct, the action
send _close _port is performed and new _state is set to port _closed.

6_._4_._3_._2_ _ _ _D_e_s_c_r_i_p_t_i_o_n_ _o_f_ _t_h_e_ _A_c_t_i_o_n_s_ 6.4.3.2

The actions are described in numerical order of the identifica-
tions. The actions, which are solely compounded by other actions,
are not mentioned.

Action 1: send _open _port
an open _port message is sent and the answer is examined. If it is
not acceptable, the terminal is delayed a certain - optional -
time and the function is repeated. When the answer is correct, an
operation with protocol _state = after _open is signalled to
start _input.

Action 2: answer _sc _connect
an sc _connect _response send message is sent and if it was suc-
cessful, an operation with protocol _state = after _sc _connect is
signalled to start _input.

Action 3: send _vtp _cacc
a letter with the VTP cacc block is sent and the conversion flag
is set to true.

Action 4: answer _appl _disconnected
the application message is returned with status = disconnected
(1<4).

Action 5: write _att
a letter with the text 'att' and your turn indication is sent and
a buffer is prepared for the receiving of text _portions.
\f

Action 6: convert _appl _name
the characters from the text _portion are converted into the buf-
fer. Maximum 12 characters are stored and the remaining charac-
ters are ignored.

Action 7: search _process
a letter with an NL primitive is sent and the buffer with the
processname is terminated by null characters. The existance of
the process is examined and if it exists, the kind is inspected
(must be an internal process). If the tests are sucessful, the
action send _att _message is performed. Otherwise a letter with an
error text is sent.

Action 8: close _help
the buffer (in the zone help) which was prepared by the action
write _att is released.

Action 9: send _att _message
an attention message is sent to the application process via the
pseudo process and the terminal is delayed until the answer is
received. If the answer has not arrived after an optional timer
period, the message is regretted and a letter with an error text
is sent.
If the terminal receives a dummy answer (i.e. result <>1), a
letter with an error text is sent. The status in the answer word
is not examined.

Action 10: send _att _message _reserved
the conversion flag is set to true and the action send _att _mes-
sage is performed.

Action 11: answer _sense _message
the sense message is answered with status OK.
\f

Action 12: prepare _input
if the process description address of the sender of the input
message is the same as the latest active process at the terminal
a letter with a your turn indication is sent. If it is another
process, the process name is copied from the process description
and the text 'to <process name>' is sent in a letter together
with a your turn indication.
If the status word of the answer on the letter message is not OK,
the action answer _appl _disconnected is performed. Otherwise the
in _mess zone is opened and the fields file count, block count and
free parameter are defined in the zone description as max _chars
in application input buffer, cur _chars (=0) and message buffer
address of the application message, respectively.

Action 13: receive _and _convert _input
if there is room for the text _portion, the characters are con-
verted and written in the in _mess zone buffer, the field
cur _chars in the zone description is updated and the next state
is set to current state.
If there is not enough free locations in the zone buffer, the
action is dummy (i.e. next state will be skipping _input).

Action 14: finish _input
the in _mess zone buffer is finished by a new line character and
the input message is answered (with status OK) by means of clo-
sing the in _mess zone. If the close was successful, a letter with
an NL primitive is sent.
Otherwise the action finish _input _after _error is performed.

Action 16: finish _input _after _error
The action answer _input _0 _bytes is performed and a letter with
the text 'last inputline skipped' is sent.
\f

Action 18: answer _input _att _reserved _and _clear
the input message is answered with status = attention (1<16) and
no bytes tranferred, the in _mess zone is closed and the actions
send _clear and send _att _message are performed.

Action 19: answer _input _0 _bytes
the input message is answered with status = timer (1<21) and no
bytes transferred and in _mess zone is closed.

Action 20: answer _input _disconnected
the input message is answered with status = disconnected (1<4)
and no bytes transferred and in _mess zone is closed.

Action 25: prepare _output
if the process description address of the sender of the output
message is not the same as the latest active process at the ter-
minal, a letter with the text 'from <process name>' is sent. The
internal operation is transferred to an output _portion operation
with start _relative = 0 and signalled to terminal _task.

Action 26: convert _and _send _output
the characters from the output message (starting at start _rela-
tive) are converted and formatted as VTP TEXT-SEG and NL pri-
mitives into a letter which is sent when the letter is exhausted
or when all the characters are handled.
If the letter is exhausted before all the characters have been
handled, the start _relative field in the output _portion operation
is updated and the operation is signalled to terminal _task.
When all the characters have been handled, the output message is
answered (with status OK).

Action 27: answer _output _ok
the output _portion operation is removed from the terminal _task
semaphore and returned to wait _message _pool before the output
message is answered with status = OK and 'start _relative' bytes
transferred.
\f

Action 30: answer _output _att _2
as action answer _output _ok except that status = attention
(1<16).

Action 33: answer _output _disconnected
as action answer _output _ok except that status = disconnected
(1<4) and no bytes transferred.

Action 37: send _clear
a telegram with telegrambyte = clear is sent.

Action 38: send _clear _mark
a letter with a clear _mark block is sent.

Action 39: answer _illegal _message
the application message is returned with result = unintelligible
(3).

Action 45: abort
an abort _request operation is sent with a cause as described in
subsection 3.2.4 and the action pass is performed.

Action 46: pass
the coroutine procedure set _priority is called twice with the
same priority as when the terminal coroutine was started, but the
standard variable co _8000 _event is negative both times. Each call
will force the centrallogic to examine the event queue and thus
activate the coroutines waiting for the events (i.e. messages and
answers).

Action 49: no _operation _received
the action is dummy except that flag, indicating that the opera-
tion received from terminal _task has been released to a pool
semaphore, is set to true.

Action 50: no _action
the action is empty, i.e. absolutely nothing is performed.
\f

Action 51: disconnect
an sc _disconnect _accept send message is sent with a cause as de-
scribed in subsection 3.2.3.

Action 52: send _close _port
a close messages is sent but neither the result nor the status
word of the answer is examined. The action pass is performed.

Action 53: fatal
the execution of the SMM program is stopped by means of a call of
system (9 <* run _time _alarm*> ...).

6_._5_ _ _ _ _ _ _ _M_a_n_i_p_u_l_a_t_i_o_n_s_ _o_f_ _V_T_P_ _T_e_x_t_ _B_l_o_c_k_s_ 6.5

In order to ease the input and output of VTP text blocks, the
procedures read _char and write are used for manipulating the con-
tents. At the same time character conversions and format trans-
formations will be made possible.

6_._5_._1_ _ _ _ _ _C_h_a_r_a_c_t_e_r_ _C_o_n_v_e_r_s_i_o_n_s_ 6.5.1

The internal alphabet is based on the ISO/ASCII alphabet. The
values 5/14 (= 94 = ), 7/14 (= 126 = ) and 7/15 (= 127 = DEL)
have non standard interpretations. The 5/14 character is used as
a shift down character and the 7/14 character is used as a shift
up character, while 7/15 is used as an internal representation of
the 0/0 ( = 0 = NUL) value.

The shift characters are used for outputting the text constants
which are formatted according to the VTP conventions. They are
necessary because the text block code and the identifications for
the primitives may have values greater than the maximum allowed
by the standard procedures (i.e. 127). Each character in a text
constant with a value greater than 127 is substituted by the cha-
racters <shift up><character value - 128><shift down> and every
occurrence of the NUL character is substituted by a DEL. If a NUL
character is not given as a DEL character, the constant is fi-\f

nished and the NUL is not written in the output buffer. By means
of the procedure write, the characters are converted yielding to
the wanted VTP format.

The conversion table for output is initiated as follows:

iso _table (out _conv _table);
out _conv _table (shift _down):= 256 <*blind*>;
out _conv _table (shift _up):= 1 shift 12 + 128;
out _conv _table (127):= 7 shift 12 + 0;
for i:= 128 step 1 until 255 do
out _conv _table (i):= 7 shift 12 + i;
out _conv _table (shift _down +128):= 1 shift 12 + 0;
out _conv _table (shift _up + 128):= 256 <*blind*>;
out _table (out _conv _table);

The conversion table for input is initiated as follows:

iso _table (in _conv _table);
in _conv _table (0):= 7 shift 12 + 0;
in _conv _table (13):= 7 shift 12 + 13;
in _conv _table (127):= 7 shift 12 + 127;
for i:= 128 step 1 until 255 do
in _conv _table (i):= 7 shift 12 + i;
in _table (in _conv _table);

In this way all character values will be significant, which is
essential for the interpretation of the VTP text blocks received
from the network.

Note that the text constants are defined before the initiation of
the input and output conversion tables.
\f

6_._5_._2_ _ _ _ _ _F_o_r_m_a_t_ _T_r_a_n_s_f_o_r_m_a_t_i_o_n_s_ 6.5.2

The reading of VTP text blocks is straightforward; the contents
are read item by item by means of read _char until the end of the
block or until the first primitive code has the value zero (i.e.
a fill character in the end of a block).

The writing of VTP text blocks is not so simple. SMM may produce
two kind of primitives, i.e. NL primitives and TEXT-SEG primi-
tives. The NL primitive is a constant string with the contents

The TEXT-SEG primitive has the format

which means that the length of the text string must be available
when the writing is started. This format is obtained by writing
the data character in a working zone buffer and when the text
string is ready the header of the primitive is written in the
output buffer and the contents of the working zone buffer are
copied to the output buffer. A TEXT-SEG primitive is produced
when

- an NL primitive must be written
- the application message buffer is emptied
- the working zone buffer is full

whichever occurs first.
\f

In order to avoid the VTP text block to exceed the limit of the
network buffer length, it is tested that there may be room for
a TEXT-SEG primitive of a maximum length (i.e. the length of the
working zone buffer). The characters from the application are
read word by word, i.e. 3 characters at a time. The algorithm for
writing VTP text blocks can be illustrated as follows

for more: = get _next _3 _chars while more and
chars _produced + max _in _text _segm <max _in _net _buffer-10 do
for char: = chars(1), chars(2), chars(3) do
if char = 10 then
finish TEXT-SEG primitive, if any
write (out _mess, nl _primitive _string)
update chars _produced
else
if legal text char then
out _char (help, char)
finish TEXT-SEG primitive, if any
send the letter

The statement 'finish TEXT-SEG primitive, if any' means

if no _of _text _chars > 0 then
out _char (out _mess, text _seg _primitive)
out _char (out _mess, no _of _text _chars)
i: = 1
write (outmess, string help <*working zone*> (increase (i)));
no _of _text _chars: = 0
update chars _produced

6_._6_ _ _ _ _ _ _ _M_a_n_i_p_u_l_a_t_i_o_n_s_ _o_f_ _Z_o_n_e_s_ 6.6

Before reading and writing of the contents in a zone buffer, the
zone description must be prepared for read _char and
write/out _char, respectively. If the characters in the zone
buffer may be treated as a text string, the zone is not prepared
for read _char. Instead the characters are made accessible in a
zone record.

After writing of a block either for the network or for an appli-
cation process, the block is forwarded to the receiver when the
associated zone is closed.

6_._6_._1_ _ _ _ _ _O_p_e_n_ _o_f_ _Z_o_n_e_s_ 6.6.1

When a zone is opened for writing, it is done to a non existing
process causing the block procedure to be activated when a block
transfer is attempted, i.e. when the buffer is full or because of
a call of setposition or close.

M_M_m_m_6.6.2 Prepare read _char 6.6.2
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

The procedure read _char is used on the multishare zone answers,
only; this means that both the share description and the zone
description must be initialized.

The share description is initialized as follows:
share state := ready
first shared index := 1
last shared index := length in hw
top transferred := first shared + length in hw \f

and the zone description is initialized as follows:
record base := first shared
last halfword := first shared + length in hw
used share := share number
partial word := first word of data buffer <8 + 1 (i.e.
second char <16 + third char <8 + 1)
state := after repeat char
record length := 0

When these initializations are done, the standard procedure
read _char can be used just as usual.

6_._6_._3_ _ _ _ _ _P_r_e_p_a_r_e_ _Z_o_n_e_ _R_e_c_o_r_d_ 6.6.3

The following initializations are done on single shared zones,
only
record base := base buffer area
record length := length in hw
last halfword := record base + length in hw
then the zone record can be accessed, e.g.
processname (1) := z(1)
processname (2) := z(2)
or
i: = 1
write (--, string z(increase (i)) --)

M_M_m_m_6.6.4 Prepare write/out _char 6.6.4
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

If the zone is just after open or setposition, nothing else is
needed before the call of the standard procedures write or
out _char. But when the zone is to be used for the same purpose a
number of times without activating the block procedure, the zone
may be prepared for the next text string by means of the follow-
ing changes in the zone description
partial word := 1
record base := base buffer area
record length := 0
provided that the zone has only one share.

6_._6_._5_ _ _ _ _ _C_l_o_s_e_ _o_f_ _Z_o_n_e_s_ 6.6.5

In order to avoid a block transfer and the call of the block
procedure, a zone may be 'closed' by means of changes in the
zone description. The changes are the same as described for
preparing for write/out _char plus
zone state := after close

6_._6_._6_ _ _ _ _ _B_l_o_c_k_ _P_r_o_c_e_d_u_r_e_s_ 6.6.6

As described in subsection 6.6.1 the block procedure is called
when the buffer is full or when the procedures close or set-
position are called.

M_M_m_m_6.6.6.1 Block Procedure answer _input 6.6.6.1
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

The block procedure answer _input is attached to the in _mess zone,
which is used for answering input messages from an application
process.

If the procedure is called because the buffer is full, it means
that the input line was too long (because the share length is
greater than the limit of the input line).

If the procedure is called when the OK flag is false, the input
message may not be returned with status = OK, so the procedure is
dummy in this case.

Before returning the answer to the application process, the mes-
sage buffer area is filled with the contents of the zone buffer
by means of the monitor procedure copy _core _area.
\f

Pseudo code:

procedure answer _input (in _mess, stat, halfwords)
if halfword <= max _allowed and ok then
if monitor (copy _core _area, in _mess, zone _description.
message _buffer, answer) = 0 then
answer.status := 0
answer.result := normal
monitor (send _answer, zone _description.message _buffer,
answer)
zone _description.message _buffer:= 0
else ok:= false
else ok:= false

M_M_m_m_6.6.6.2 Block Procedure send _output 6.6.6.2
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

The block procedure send _output is attached to the out _mess zone,
which is used for forwarding send messages to the network (i.e.
NPM).

The out _mess zone is defined with a share length greater than the
length of a network operation, so if the block procedure is cal-
led because the buffer is full, it is a fatal error and the whole
SMM program execution must be aborted.

Pseudo code:

procedure send _output (out _mess, stat, halfwords)
if halfwords <= max _allowed then
message.operation _mode := output _mode
message.port _address := ports (term _task)
message.sc _mode := mode (e.g. send _letter, sc _disc _accept)
set zone name to name of NPM process
send message
wait answer
reset zone name to dummy name
else system (run _time _alarm --)

M_M_m_m_ 6.6.6.3 Block Procedure write _text _seg 6.6.6.3
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

The block procedure write _text _seg is attached to the help zone,
which is a working zone for preparing VTP TEXT-SEG primitives,
receiving process names and the like. The block procedure is
called only when TEXT-SEG primitives are produced.

The data buffer is written in the real output buffer (i.e.
out _mess) after the TEXT-SEG header and preparations are made for
the next TEXT-SEG primitive.

Pseudo code:

procedure write _text _seg (help, stat, halfwords)
prepare zone record
if no _of _text _chars> 0 then
out _char (out _mess, TEXT-SEG primitive identification)
out _char (out _mess, no _of _text _chars)
no _of _text _chars:= 0
index:= 1
write (out _mess, string help (increase (index)))
\f

F_ 7_._ _ _ _ _ _ _ _ _T_E_S_T_ _A_N_D_ _D_E_B_U_G_ _T_O_O_L_S_ 7.

The SMM program offers a number of test and debug facilities,
which are activated via the fp parameters in the start up of the
program.

7_._1_ _ _ _ _ _ _ _T_e_s_t_o_u_t_p_u_t_ 7.1

The coroutine procedures, e.g. centralogic, signal and wait, pro-
duce test records in a (disc)file in case the standard variable
select _test is assigned properly. See ref. 7. Besides the
automatical generated test records, so-called user records may be
created by the SMM program.

The purpose of the testoutput is to follow the execution of the
program, e.g. observe the scheduling of the coroutines and dis-
play certain variables at main points during the work.

The testoutput facility is started if the program parameter ctest
is different from zero. The standard variable select _test is
initialized with the value of ctest before the coroutines are
started. The document name of the discfile holding the testoutput
is given in the testname parameter. If the discfile must not be
extended when it is filled, but used cyclically, the parameter
cyclic must have the value yes, otherwise the file is extended as
long as necessary (and possible).

When the SMM program is stopped in such a way that the traprou-
tine is executed (i.e. break or fatal program error), the test-
output zone is closed in order to transfer the latest test re-
cords to the discfile.

7_._1_._1_ _ _ _ _ _U_s_e_r_ _R_e_c_o_r_d_s_ 7.1.1

The user records are produced if the parameter ctest is different
from zero in the following situations

- when the next step of the finite automaton is to be executed in
the terminal coroutine, i.e. when the next symbol is received
and the action and next state is defined (main _loop).

- when the block procedure answer _input is called.

- when the block procedure send _output is called.

- when the status word is not OK in an answer on a send operation
to the network.

- before the execution of a call of the procedure perform, i.e.
actions.

- when a message is sent to the network, i.e. receive, send, open
and close message.

- when an answer to an application message is sent.

Each user record as a format acceptable for the coroutine system,
i.e.

- record length is 8 words
- first word contains the type identification
- sixth word is the coroutine number
- seventh + eighth word is current clock delivered by
the procedure prepare _test.
\f

The contents of the user records are given in fig. 9.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _w_o_r_d_ _1_ _w_o_r_d_ _2_ _ _ _ _w_o_r_d_ _3_ _ _ _ _ _ _ _w_o_r_d_ _4_ _ _ _ _w_o_r_d_ _5_ _ _ _
m_a_i_n_ _l_o_o_p_ _ _ _ _ _ _ _ _1_0_2_4_+_1_ _c_u_r_._s_t_a_t_e_ _s_y_m_b_o_l_ _ _ _ _ _ _ _a_c_t_i_o_n_ _ _ _ _n_e_w_ _s_t_a_t_ _
answer input 1024+2 halfwords state:
1 ok 0 messaddr
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _0_ _n_o_t_ _o_k_ _ _ _ _ _0_ _ _ _ _ _ _ _ _ _ _0_ _ _ _ _ _ _ _
s_e_n_d_ _o_u_t_p_u_t_ _ _ _ _ _ _1_0_2_4_+_3_ _h_a_l_f_w_o_r_d_s_ _m_a_x_ _h_w_ _ _ _ _ _ _ _m_o_d_e_ _ _ _ _ _ _ _0_ _ _ _ _ _ _ _
s_t_a_t_u_s_ _(_o_u_t_p_u_t_)_ _ _1_0_2_4_+_4_ _s_t_a_t_u_s_ _ _ _ _0_ _ _ _ _ _ _ _ _ _ _ _ _0_ _ _ _ _ _ _ _ _ _ _0_ _ _ _ _ _ _ _
p_e_r_f_o_r_m_ _ _ _ _ _ _ _ _ _ _1_0_2_4_+_5_ _a_c_t_i_o_n_ _ _ _ _0_ _ _ _ _ _ _ _ _ _ _ _ _0_ _ _ _ _ _ _ _ _ _ _0_ _ _ _ _ _ _ _
send message 1024+6 halfwords operation<12 port mess
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _+_ _m_o_d_e_ _ _ _ _ _ _ _a_d_d_r_ _ _ _ _ _ _ _a_d_d_r_ _ _ _ _
s_e_n_d_ _a_n_s_w_e_r_ _ _ _ _ _ _1_0_2_4_+_7_ _h_a_l_f_w_o_r_d_s_ _s_t_a_t_u_s_ _ _ _ _ _ _ _r_e_s_u_l_t_ _ _ _ _ _m_e_s_s_a_d_d_r_

Figure 9: Survey of the user records.

7_._1_._2_ _ _ _ _ _P_r_i_n_t_i_n_g_ _t_h_e_ _T_e_s_t_o_u_t_p_u_t_ 7.1.2

The testoutput file can be printed either by means of the fp
program print as described in ref. 7 or by means of an ALGOL
program using the external procedure test _print as described in
ref. 8.

The test _print procedure produces a listing of the records where
coroutines, semaphores and test record types are written as text
and not as numbers. This means that to a large extent the listing
can be used immediately, i.e. without prior interpretation.

7_._1_._3_ _ _ _ _ _B_l_o_c_k_ _P_r_o_c_e_d_u_r_e_ 7.1.3

The testoutput zone is provided with the block procedure
test _error.

If test _error is called with the end-of-document bit (1<18) and
the program parameter cyclic is yes, the zone is positioned to
the first segment of the disc file and the block is written there
before the procedure returns.
\f

If test _error is called with any other status bits or if cyclic
in no, the generating of records is stopped (select _test = ctest
= 0) and a warning is written on current output.

7_._2_ _ _ _ _ _ _ _L_o_g_ _P_r_i_n_t_o_u_t_ 7.2

The coroutine procedure centra _logic produces log on current
output with the semaphore table at call and/or return controlled
by the program parameter log. The values of log are described in
ref. 7.

7_._3_ _ _ _ _ _ _ _T_r_a_c_e_ _o_f_ _M_e_s_s_a_g_e_s_ _a_n_d_ _A_n_s_w_e_r_s_ 7.3

The messages and answers received and sent by SMM can be traced
together with the contents of the data buffer received/sent. The
messages and answers concerning testoutput, current input and
current output are not traced.

The facility is activated if the program parameter trace is yes.

The output is printed on current output and has the following
contents

traced message (<message buffer address>)
<next buffer><previousbuffer><receiver or answer type><sender>
<message word 1><message word 2>...<message word 8>

traced answer (<message buffer address>)
<answer word 1><answer word 2>...<answer word 8>

traced buffer area (<first halfword>,<last halfword>)
<char 1><char 2>...<char 12>
<char 13><char 14>...<char 24>
.
.
.
\f

where <char i> is a description of the character number i written
as the decimal value of the character and the graphic
representation or a space if the character value is less than 33
or greater than 125.

See example 2.

Example 2: The printout with trace.yes.
Note the verifications of the program parameters
before the trace is started.

7_._4_ _ _ _ _ _ _ _P_s_e_u_d_o_n_e_t_ 7.4

The pseudonet substitutes the network interface and therefore the
whole network too. It has been implemented in order to debug the
SMM module as a stand-alone program.

The pseudonet receives all the messages destinated for Network
Port Module (NPM) and creates answers to them controlled by the
input commands read from current input.

The pseudonet is used if the program parameter pseudonet is yes.
It is implemented as a part of the SMM program. Nevertheless the
communication is realistic enough, because the entry to the
pseudonet is implemented as a pseudo process, (with the name
given in the program parameter netname). See fig. 10.

Figure 10: Pseudo process as pseudonet.

7_._4_._1_ _ _ _ _ _P_r_o_g_r_a_m_ _S_t_r_u_c_t_u_r_e_ 7.4.1

The flow of operations, messages and answers are illustrated in
fig. 11.

Figure 11: Operation flow between SMM and pseudonet.

The pseudonet consists of two coroutines, npm _message and
npm _answer, and a 'common' procedure answer _npm _message.

7_._4_._2_ _ _ _ _ _S_e_m_a_p_h_o_r_e_s_ 7.4.2

The pseudonet uses four (user defined) semaphores, i.e.

open _pool (7) used for open request operations
event _pool (8) used for queueing receive opera-
tions for event _control; one opera-
tion for each receive message sent
to NPM with sc _mode = event _con-
trol. The semaphore holds all event
controls with no respect to the
port number
telegram _pool (9) as event _pool but concerning re-
ceive _telegram operations
letter _pool (10) as event _pool but concerning re-
ceive _letter operations.

Beside these semaphores the pseudonet shares the following
semaphores with the SMM program (see section 5.1):

wait _message (-1)
wait _message _pool (0)
message _pool (2)

7_._4_._2_._1_ _ _ _I_n_i_t_i_a_l_i_z_a_t_i_o_n_ _o_f_ _S_e_m_a_p_h_o_r_e_s_ 7.4.2.1

The semaphores are initialized together with the other semaphores
in the SMM program before the execution of the coroutines (see
subsection 5.1.1).

semaphore operation number of operations
size (HW) per terminal
wait _message _pool 22 1 + <inputs per term>
message _pool 22 1 + <inputs per term>

7_._4_._3_ _ _ _ _ _O_p_e_r_a_t_i_o_n_s_ 7.4.3

The operations signalled to the semaphores wait _message,
wait _message _pool and message _pool are similar to those described
in section 5.2.

The operations signalled to the semaphore open _pool have the fol-
lowing format

field type name
1 i -
2 i -
3 i buffer = message buffer address of the open
operation

The operations signalled to the semaphores event _pool,
telegram _pool and letter _pool have the same format as follows

field type name
1 i -
2 i (port) = actual port address
3 i buffer = message buffer address of the input
operation

7_._4_._3_._1_ _ _ _S_u_r_v_e_y_ _o_f_ _O_p_e_r_a_t_i_o_n_s_ 7.4.3.1

semaphore
name generated by source destination
open npm _message message _pool open _pool
event npm _message message _pool event _pool
telegram npm _message message _pool telegram _pool
letter npm _message message _pool letter _pool

7_._4_._4_ _ _ _ _ _C_o_r_o_u_t_i_n_e_s_ 7.4.4

The coroutines npm _message and npm _answer have one incarnation
each and their identifications are

name identification
npm _message 3 + terms * 2
npm _answer 4 + terms * 2

M_M_m_m_7.4.4.1 Coroutine npm _message 7.4.4.1
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

The npm _message coroutine receives all messages destinated for
the network process.

Pseudo code:

procedure npm _message (npm _process);
activ (1):= ...:= activ (terms):= closed;
repeat
wait _select:= npm _process;
wait (wait _message, message _op);
case message _op. message _area. operation _mode do
open _port: queue an open operation on open _pool semaphore
close _port: activ (port address):= closed
answer message _op. buffer with status = ok
input: if activ (port address) = closed then
answer message _op. buffer with status = act _timeout
else
queue an operation on event _pool, telegram _pool or
letter _pool semaphore
output: if activ (port address) = closed then
answer message _op. buffer with status =
ack _timeout
else
answer message _op. buffer with status = ok
signal (wait _message _pool, message _op);
until false;
\f

Close messages are answered immediately with status = 0, and the
state of the port is set to closed in the port survey
(activ(port):= 0).

Output messages (i.e. send operations) are answered immediately
too, but the status depends on the state of the port; status = 0
if the port is open (activ(port) <> 0) and status = 1<20 (i.e.
ack _timeout) if the port is closed.

If the port is closed, input messages (i.e. receive operations)
are answered with status = 1<20 (i.e. ack _timeout). On the other
hand if the port is open, the input message is queued on one of
the semaphores letter _pool, telegram _pool and event _pool
depending on the sc _mode in the message.

Open messages are - in any case - queued on the semaphore
open _pool.

M_M_m_m_ 7.4.4.2 Coroutine npm _answer 7.4.4.2
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

The npm _answer coroutine reads commands from current input. A
command is a description of a task which is either an answer to
an input or an open operation or it is an order to delay the
execution of answers.
\f

Pseudo code:

procedure npm _answer;
while read _char (in, task) <> EM do
read port number
if task = wait then
delay port number/10 seconds
else
if task = open then
wait (open _pool, term _op);
activ (pool number):= open;
answer term _op. buffer with status = ok
signal (message _pool, term _op);
else <* task = event, telegram or letter *>
if activ (port number) = closed then
return all the messages queued for this port on
the pool semaphores with status = term _by _req
else
wait _select:= port number;
wait (event/telegram/letter _pool, term _op);
if event control then
repeat read _char (in, function)
until legal function
repeat
read (in, char _value);
if char _value >= 0 and <= 255 then
store char _value
else
if char _value = 256 then
read _string (in, string) and store string
until next char = NL

answer term _op. buffer with status = ok
and the stored characters

<*end input *>

repeat
pass with priority less than other coroutines
answer all the messages queued on 'the pool semaphores with
status = term _by _req
until no operations on the pool semaphores
pass
wait (open _pool, term _op);
answer the open message with status = term _by _req
signal (message _pool, term _op);

Note that every parameter read from current input is echoed on
current output as a verification of the input.

7_._4_._5_ _ _ _ _ _I_n_p_u_t_ _C_o_m_m_a_n_d_s_ _a_n_d_ _V_e_r_i_f_i_c_a_t_i_o_n_ 7.4.5

7_._4_._5_._1_ _ _ _I_n_p_u_t_ _S_y_n_t_a_x_ 7.4.5.1

Task Command Syntax Event results
open o<port address> *
telegram t<port address> <element>*
c connect request
d disconnect request
M_M_m_ a abnormal termination
event e<port address> <element>* NL EM
P_P_p_ l low layer error
p protocol error
i illegal
letter 1<port address> <element>*
wait w<time>

where
<port address> is a number from 1 to number of ter-
minals

<element>* is a list of parameters to be used in
the answer. There could be none, one or
more parameters for one answer. Each element
results in one character in the answer. An
element is either an integer with the
character value or it is a textstring. If it
is a textstring, the element starts with the
number 256 and one character ending the
reading of the number (e.g. one space); The
textstring itself is ended by a delimiter
(class > 6, e.g. space).

<time> is a number determining the waiting time given
as number of seconds times ten.

NL is the character value 10.

EM is the character value 25.
\f

The letters in front of the commands are read by read _char and
the succeeding integer is read by the standard procedure read,
leaving the possibility of writing letters, delimiters etc. be-
tween the leading letter and the integer.

The open and the wait command are skipping all characters until
the next NL or EM character. The event command skips all charac-
ters after the port address until the first letter in the range
of a to z. This letter is interpreted as a result and all illegal
letters are treated as i.

The elements are read by the standard procedure read; when an
element equals 256, a text is read by means of read _string. The
list of elements is ended when the last read character is either
NL or EM. This implementation permits comments consisting of let-
ters, delimiters etc. between the elements.

Example 3 shows a legal sequence of commands for the pseudonet.
\f

Example 3: Commands for the pseudonet which form an ordinary
SMT-SMM communication.

7_._4_._5_._2_ _ _ _V_e_r_i_f_i_c_a_t_i_o_n_ 7.4.5.2

Whenever the pseudonet reads an element of a command, it is
echoed on current output as a verification. The output does not
contain the characters skipped between the elements. See example
4 which is the output from a test with the input described in
example 3.

Example 4: Verification of the commands described in example 3.

F_ 8_._ _ _ _ _ _ _ _ _P_R_O_G_R_A_M_ _E_X_E_C_U_T_I_O_N_ 8.

8_._1_ _ _ _ _ _ _ _R_e_s_o_u_r_c_e_ _D_e_m_a_n_d_s_ 8.1

The SMM module must be executed with sufficient resources of
primary storage (size), message buffers (buf), area processes
(area) and disc storage (perm/temp). All requirements are based
on release 1.20 of the SMM module.

8_._1_._1_ _ _ _ _ _S_i_z_e_ 8.1.1

The storage demands can be estimated as a sum of

- standard requirements (FP, RS etc.)
- program segments
- variables.

The standard requirements are

HW
file processor (FP) 1536
running system (RS) 3072
in and out zone 1024
working locations, approx. 1_0_0_0_
6_6_3_2_

The translated program requires during execution:

HW
segment table 362
program segments 4_6_3_3_6_
4_6_6_9_8_

The estimations of storage locations for program segments are
based on the rule that half the program must be in primary sto-
rage (i.e. 181 segments /2 = 90.5 segments = 90.5*512 HW)
\f

The number of variables depends on the program parameters
<terms>, <letters per terminal>, <trace> and <pseudonet>:

HW
own variables 0
global variables 6
2100
2736 + terms*12
+ terms*(2+letters)*172
X
coroutine descriptions 40 + terms*40
semaphore descriptions 160 + terms* 8
semaphore operations 0 + terms*(288+letters*198)
coroutines:
start _network _input 524
network _input 670
terminal Y + terms*1304
appl _message _ _ _ _ _ _ _0_ _+_ _t_e_r_m_s_*_ _6_2_6_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
X+Y+6236 + terms*(2622+letters*370)

if pseudonet:
coroutine descriptions 40
semaphore operations 0 + terms*(132+letters* 44)
npm _message 532
npm _answer _ _ _1_1_0_0_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
1672 + terms*(132+letters* 44)

The parameter X is 0 if <trace> is no, but if <trace> is yes, X
is the maximum number of halfwords in a message or in an answer.
The parameter Y is the maximum number of halfwords in an appli-
cation output message.
\f

The total storage requirements are

HW
standard requirements 6632
variables 7236 + terms*(2622+letters*370)
program 4_6_6_9_8_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
6_0_5_6_6_ _+_ _t_e_r_m_s_*_(_2_6_2_2_+_l_e_t_t_e_r_s_*_3_7_0_)_ _ _ _

provided that X+Y = 1000 HW and that the pseudonet is not
activated.

8_._1_._2_ _ _ _ _ _B_u_f_ 8.1.2

The message buffer demands are

running system (RS) 1
in + out 2
network input messages 1 + terms*(2+letters)
testoutput (if ctest<>0) 1
attention messages 0 + terms
TEXT-SEG packing 0 + terms
answer application input 0 + terms
network output messages 0_ _+_ _t_e_r_m_s_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
5_ _+_ _t_e_r_m_s_ _*_(_6_+_l_e_t_t_e_r_s_)_ _ _

In addition the pseudonet requires terms*(4+letters) message buf-
fers if it is activated.

8_._1_._3_ _ _ _ _ _A_r_e_a_ 8.1.3

The execution requires area processes as follows

standard 2
pseudo processes 0 + terms
testoutput (if ctest <>0) 1
in+out (if bs areas) 2
pseudonet (if active) 1

During normal production the process requires 3_+_t_e_r_m_s_ area
processes.

8_._2_ _ _ _ _ _ _ _P_r_e_r_e_q_u_i_s_i_t_e_s_ 8.2

The software prerequisites are

SW8001/1 Basissystem release 1.0 or newer releases
SW8101/1 BOSS release 15.0 or newer releases.

8_._3_ _ _ _ _ _ _ _P_r_o_g_r_a_m_ _P_a_r_a_m_e_t_e_r_s_ 8.3

The program parameters are options to the execution of the SMM
module. The parameters are given as fp-parameters when the pro-
gram is started.

Omitted parameters or illegal parameter values will cause the
default value to be used.

8_._3_._1_ _ _ _ _ _S_u_r_v_e_y_ _o_f_ _P_r_o_g_r_a_m_ _P_a_r_a_m_e_t_e_r_s_ 8.3.1

name.default description
(_m_i_n_,_ _m_a_x_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

terms.1 number of terminals; one terminal =
(1, 50) one port

first.1 identification number of the pseudo
(1, 500) process associated to the first
terminal. The names of the pseudo-
processes are
smm<first>, smm<first+1> ...

letters.1 number of receive letter operations
(1, 10) sent to the network per terminal

recmask1.65535 first 16 bits of the receiver mask
(0,2**16-1=65535) used in open messages
\f

recmask2.65535 last 16 bits of the receiver mask
(0,2**16-1=65535) used in open messages

delay.300 delay after an unsuccesful open
(1, 3000) attempt until the next one. The
timer count is stated as 10 times
the wanted seconds, e.g. the de-
fault is half a minute

waitatt.300 timeout limit for the answer on an
(1, 3000) attention message (sent to the
application). The default is half a
minute

netname.npm process name of the network port
module in RC8000 (or the pseudo-
process when the pseudonet is ac-
tivated)

pseudonet.no = no : normal work
(no, yes) = yes: the network is simulated via
current input and a pseudo
process

log.0 test output parameter for the
(0, 15) coroutine system

ctest.0 test output parameter for the
(0, 255) coroutine system

testname.smmtest document name of the backing sto-
rage area for test records.
Relevant only when ctest <> 0
\f

cyclic.yes = yes: the testoutput document must
(yes, no) be used from the beginning
again when end _of _document
is met, i.e. cyclically

= no : the testoutput document must
be extended when end _of _do-
cument is met.
Relevant only when ctest <> 0

trace.no = yes: messages and answers must be
(no, yes) traced on current output
= no : no printout of messages/
answers.

8_._4_ _ _ _ _ _ _ _P_r_o_g_r_a_m_ _S_t_a_r_t_ _U_p_ 8.4

The SMM module is started in an internal process with sufficient
resources and with user bases equal to system bases (i.e.
-8388607 8388605). If the user bases do not equal the system
bases, it is impossible to get contact with the operating system
's' from the terminals (alias the pseudo processes). The name of
the process is the identifications of the ports at the SC level.

If the system should serve 8 terminals with 2 letters per
terminal and the testoutput must be delivered in the bs file
'smmtestmax' (which must not be extended) and the npm process is
named 'npm3', the following resources are required:

size: 60566 + 8 * (2622+2*370) = 87462 HW
buf : 5 + 8 * (6+2) = 69
area: 2 + 8 + 1 = 11

Thus the process may be defined as follows

new smm size 90 000 buf 69 area 11 base -8388607 8388605 run

and the program, named smmp could be activated as follows

smmp terms.8 letters.2 netname.npm3,
ctest.255 testname.smmtestmax

8_._5_ _ _ _ _ _ _ _E_r_r_o_r_ _M_e_s_s_a_g_e_s_ 8.5

There are two kinds of error messages; warnings and alarms.

8_._5_._1_ _ _ _ _ _W_a_r_n_i_n_g_s_ 8.5.1

Warnings are printouts on current output indicating an error but
the execution keeps going.

There is only one warning:

testoutput stopped, status = ..., halfwords = ...,
segment count = ...

this implies that the production of testoutput is stopped because
of an illegal status.

8_._5_._2_ _ _ _ _ _A_l_a_r_m_s_ 8.5.2

Alarms are printouts on current output when the execution of SMM
is stopped. They are all serious errors which cannot be repaired
by SMM, e.g. program errors (index, field and the like) and the
network program is not accessible.

The alarms provided by the ALGOL8 running system are not listed,
but can be found in ref. 7, 8 and 10.

The alarms are given in alphabetical order.

appl mess <res> One of the appl _message coroutines
cannot be started. <res> is the
result received from the ALGOL8
procedure new _activity, cf. ref.
10.
\f

break 6 Too many buffers used, cf. ref.
9.

fatal <no> A fatal error has been discovered
and <no> =
1 an output message to the network
is greater than the network buf-
fer size
2 the application process, which
has sent a message to SMM, is
not available when SMM wants to
access its process description
in order to get its name
3 illegal action
4 illegal state
5 operation received from the
delay semaphore
7 pseudonet only: the message area
cannot be accessed
8 pseudonet only: the answer area
cannot be accessed
9 pseudonet only: the buffer area
of a message or an answer cannot
be accessed.

netinput <res> As 'appl mess' but concerning the
network _input coroutine.

npm ans <res> As 'appl mess' but concerning the
pseudonet coroutine: npm _answer.

npm mess <res> As 'appl mess' but concerning the
pseudonet coroutine: npm _message.

npm res <res> Dummy answer received from the npm
process. <res> is the result from
the monitor function wait _answer
(18), cf. ref. 2.
\f

ps create <res>*1000 + <index>
if <res> is greater than zero then
the creation of the pseudo process
corresponding to <index> was un-
successful. <res> is the result
received from the monitor function
create _pseudo _process (80), cf.
ref. 11.

If <res> is zero the creating of
the pseudo process corresponding to
<index> was reported correctly but
the investigation of the process
description by means of the monitor
function process _description (4)
failed.

<index> less than or equal to the
number of terminals indicates
pseudo processes named
'smm<first>', 'smm<first+1>' and so
on, while <index> equal to 1 +
number of terminals indicates the
pseudonet named 'npm' or the name
given as fp-parameter 'netname' in
the call of SMM.

start <res> As 'appl mess' but concerning the
start _network _input coroutine.

terminal <res> As 'appl mess' but concerning one
of the terminals.

8_._6_ _ _ _ _ _ _ _P_r_o_g_r_a_m_ _C_l_o_s_e_ _D_o_w_n_ 8.6

The execution of the program may stop either because of an alarm
or an operator initiative. The operator may suspend the execution
by means of the break command.

Before the program stops, it tries to close all the ports and to
remove the pseudo processes created for the terminals and the
pseudonet. These actions are provided by the trap routine. In
order to inform the operator about the state of the clearing, the
trap routine produces a printout at entry, when a close port
attempt has been performed, when a remove pseudo process has been
executed and finally at exit. At last the ALGOL8 printout 'end
<blockread>' will appear.

If the operator tries to stop the execution by any other means
than the break command, the cleaning will not be completed, i.e.
pseudo processes will persist and ports are still reserved.

8_._7_ _ _ _ _ _ _ _S_y_s_t_e_m_ _G_e_n_e_r_a_t_i_o_n_ 8.7

The SMM program is written in ALGOL and must be translated by the
software package

SW8500/1 ALGOL release 12.0 or newer

and the coroutine system

SW8240/1 Coroutine System release 1.0

must be available during the compilation.

The standard procedure write must be newer than the one released
in release 12.0 of the ALGOL package, because it must be able to
handle shift-in and shift-out characters in a conversion table
defined by means of the standard procedure out _table.
\f

F_
\f

F_ A_._ _ _ _ _ _ _ _ _R_E_F_E_R_E_N_C_E_S_ A.

1 RCSL No 31-D580:
R_C_8_0_0_0_ _T_e_r_m_i_n_a_l_ _P_r_o_c_e_s_s_
Palle Andersson, September 1979.
A_b_s_t_r_a_c_t_: This paper describes the conventions of an
external process controlling a terminal connected to RC8000.
Replaces RCSL No 31-D538.
(10 printed pages).

2 RCSL No 31-D477:
R_C_8_0_0_0_ _M_o_n_i_t_o_r_,_ _P_a_r_t_ _2_,_ _R_e_f_e_r_e_n_c_e_ _M_a_n_u_a_l_.
Tove Ann Aris, Bo Tveden-Jørgensen, January 1978.
A_b_s_t_r_a_c_t_: This manual describes monitor conventions, monitor
procedures and format of monitor tables.
(129 printed pages).

3 RCSL No 43-GL11417:
C_E_N_T_E_R_N_E_T_,_ _N_e_t_o_w_r_k_ _P_o_r_t_ _M_o_d_u_l_e_ _-_ _N_P_M_,_ _R_e_f_e_r_e_n_c_e_ _M_a_n_u_a_l_
Niels Carsten Jensen, August 1981.
A_b_s_t_r_a_c_t_: This manual describes the Network Port Module
(NPM) which implements the Host Port Protocol (HPP) in the
RC8000 computer. The HPP is used in CENTERNET to connect a
host computer with the network.
(28 printed pages).

4 RCSL No 43-GL11412:
C_E_N_T_E_R_N_E_T_,_ _X_._2_8_ _S_c_r_o_l_l_ _M_o_d_e_ _T_e_r_m_i_n_a_l_ _S_u_p_p_o_r_t_,_ _R_e_p_o_r_t_.
Inger Marie Toft Hansen
(Not printed yet).

5 RCSL No 43-GL11428:
C_E_N_T_E_R_N_E_T_,_ _V_i_r_t_u_a_l_ _T_e_r_m_i_n_a_l_ _P_r_o_t_o_c_o_l_ _(_V_T_P_)_,_ _R_e_p_o_r_t_.
Per Høgh, Inger Marie Toft Hansen.
A_b_s_t_r_a_c_t_: This document contains the specifications of the
Virtual Terminal Protocol for CENTERNET. The protocol covers
the three terminal classes, data entry, scroll and native.
The protocol definition is mainly based on the Data Entry
protocol for EURONET (VTP-D/Issue 4). Scroll and native mode
terminals and parameters selecting during a session have
been added.
(Not printed yet).
\f

6 RCSL No 43-GL11341
C_E_N_T_E_R_N_E_T_,_ _R_C_8_0_0_0_ _N_e_t_w_o_r_k_ _A_c_c_e_s_s_,_ _P_r_o_g_r_a_m_m_i_n_g_ _G_u_i_d_e_
Karsten Kynde, August 1981.
A_b_s_t_r_a_c_t_: This paper describes the network access methods to
be used when the RC8000 is employed as a Host to CENTERNET.
(40 printed pages).

7 RCSL Nr 31-D639:
A_L_G_O_L_ _C_o_r_o_u_t_i_n_e_ _S_y_s_t_e_m_,_ _B_r_u_g_e_r_v_e_j_l_e_d_n_i_n_g_
Jesper Andreas Tågholt, Oktober 1981.
R_e_s_u_m__: Denne manual beskriver et coroutine system til brug
under ALGOL8.
(50 trykte sider).

8 RCSL Nr 31-D666:
A_L_G_O_L_ _C_o_r_o_u_t_i_n_e_ _S_y_s_t_e_m_,_ _T_e_s_t_u_d_s_k_r_i_v_n_i_n_g_,_ _B_r_u_g_e_r_v_e_j_l_e_d_n_i_n_g_
Lis Clement, November 1981.
R_e_s_u_m__: Dette skrift beskriver en metode til flexibel
udskrivning af test filer genereret af RC8000 Coroutine
System.
(20 trykte sider).

9 RCSL No 42-i0781:
A_L_G_O_L_7_,_ _U_s_e_r_'_s_ _M_a_n_u_a_l_,_ _P_a_r_t_ _1_._
Bodil Larsen, August 1979.
A_b_s_t_r_a_c_t_: Description of the ALGOL7 programming language.
(148 printed pages).

10 RCSL No 31-D581:
A_L_G_O_L_8_
Jørgen Zachariassen, November 1979.
A_b_s_t_r_a_c_t_: Description of the ALGOL8 programming language, as
extensions to ALGOL7. ALGOL8 includes the activity concept,
allowing procedures to act as coroutines with current I/O
transfers, format 8000 procedures for IBM3270 compatible
transaction processing, new layout possibilities, character
constants and a few minor changes to ALGOL7.
\f

F_ B_._ _ _ _ _ _ _ _ _I_N_D_E_X_ B.

B_._1_ _ _ _ _ _ _ _S_u_r_v_e_y_ _o_f_ _F_i_g_u_r_e_s_ B.1

PAGE
Figure 1: Normal operation flow ............................ 25
Figure 2: Start and stop of operation flow ................. 28
Figure 3: Structure of the program text .................... 31
Figure 4: Outline of start, connect and stop a terminal .... 47
Figure 5: Outline of the normal work of a terminal ......... 49
Figure 6: Outline of clear mechanism ....................... 50
Figure 7: Survey of the automaton .......................... 51
Figure 8: Survey of actions ................................ 52
Figure 9: Survey of user records ........................... 70
Figure 10: Pseudoprocess as pseudonet ....................... 73
Figure 11: Operation flow between SMM and pseudonet ......... 74

B_._2_ _ _ _ _ _ _ _S_u_r_v_e_y_ _o_f_ _E_x_a_m_p_l_e_s_ B.2

Example 1: Virtual terminals connected as RC8000 terminals .. 1
Example 2: The printout with trace.yes ...................... 72
Example 3: Commands for the pseudonet which form an
ordinary SMT-SMM communication ................... 82
Example 4: Verification of the commands described
in example 3 ..................................... 83

F_
\f

T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_

1. INTRODUCTION ........................................... 1

2. INSTALLATION ........................................... 2

3. KEYBOARD ............................................... 3

4. STARTING DATASTAR ...................................... 4

5. SCREEN CONTROL ......................................... 5

6. PRINTERS ............................................... 6

A_P_P_E_N_D_I_C_E_S_:

A. REFERENCES ............................................. 7

B. FUNCTION KEYS .......................................... 8
B.1 Function Keys DATASTAR ............................ 8
B.2 Function Keys FORMGEN ............................. 9

ii
\f

1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_C_T_I_O_N_ 1.

The present issue of DataStar 1.101 has been adapted specially
for use on your RC855 Work Station.

The DataStar package your have received contains the following:

- This manual "DataStar for the RC700 Microcomputer System, In-
stallation Guide".

- MicroPro's documentation of DataStar:
- DataStar, User's Guide.

- A diskette containing the DataStar system.

Do not write on the original distribution diskette as it is your
master copy and serves as last back-up in case of grave errors.
\f

F_ 2_._ _ _ _ _ _ _ _ _I_N_S_T_A_L_L_A_T_I_O_N_ 2.

Make a copy of the original DataStar distribution diskette.

Transfer all the DataStar files to a CP/M system diskette.

The DataStar standard system need no further installation or
modification.

F_ 3_._ _ _ _ _ _ _ _ _K_E_Y_B_O_A_R_D_ 3.

The DataStar system installed only makes use of the standard keys
on the keyboard, i.e. alphabetic, numeric and special characters.
Included on the distribution diskette your will find two pro-
grams, EXTDS and EXTFG, which must be executed if you want to
utilize the special keys on the RC700 keyboard. Appendix B con-
tains a list of the special keys and their functions in DataStar.

EXTDS and EXTFG apply only to the latest production of the RC700
keyboards, i.e. RC721 with production number after KBU723 serial
number 50 and RC722 with production number after KBU722 serial
number 383, see ref. 1, appendix D.

EXTDS handles the data entry program DATASTAR.
EXTFG handles the form-generating program FORMGEN.

Example of call:

A>EXTDS DATASTAR

A>EXTFG FORMGEN
\f

F_ 4_._ _ _ _ _ _ _ _ _S_T_A_R_T_I_N_G_ _D_A_T_A_S_T_A_R_ 4.

Once installed, the data entry program is started by typing the
name of the command file, normally DATASTAR, possibly followed by
the name of the data entry form wanted.

The form-generating program is started by typing the command file
name, normally FORMGEN.
\f

F_ 5_._ _ _ _ _ _ _ _ _S_C_R_E_E_N_ _C_O_N_T_R_O_L_ 5.

The highlight facility of DataStar has been disabled (the control
0 and control L functions in FORMGEN), the implementation of this
facility in DataStar conflicts with the CP/M-BIOS interpretation
of screen attributes.

The addressing mode of DataStar is horizontal, vertical position
(CONFI; cursor addressing 1: H, V).

F_ 6_._ _ _ _ _ _ _ _ _P_R_I_N_T_E_R_S_ 6.

The printer normally used by your CP/M system can be used by the
DataStar system without modifications.
\f

F_ A_._ _ _ _ _ _ _ _ _R_E_F_E_R_E_N_C_E_S_ A.

1 RCSL No 42-i1995:
CP/M for the RC700 Microcomputer System, User's Guide
\f

F_ B_._ _ _ _ _ _ _ _ _F_U_N_C_T_I_O_N_ _K_E_Y_S_ B.

B_._1_ _ _ _ _ _ _ _F_u_n_c_t_i_o_n_ _K_e_y_s_ _D_A_T_A_S_T_A_R_ B.1

Key: = Function: = Command:

m_ ESC = ESCAPE = ESC
= WORD RIGHT = @F
= WORD LEFT = @A
RUBOUT = DELETE CHARACTER LEFT = DEL
CLEAR = NOT USED =
= FIRST FIELD = @T
PA1 = NEXT RECORD = @N
PA2 = PREVIOUS RECORD = @P
PA3 = RESTORE SCREEN = @Z
PA4 = END ENTRY = @B
PA5 = EXIT CURRENT FORM = @E
= NOT USED =
= NOT USED =
= CURSOR LEFT = @S
= CURSOR RIGHT = @D
PF1 = DELETE CHARACTER = @G
PF2 = NOT USED =
PF3 = NOT USED =
PF4 = INSERT HOLE = @V
PF5 = PRINT FORM = @U
PF6 = PRINT DATA = @O
PF7 = NOT USED =
PF8 = HELP = @J
p_ = CARRIAGE RETURN = CR

F_ B_._2_ _ _ _ _ _ _ _F_u_n_c_t_i_o_n_ _K_e_y_s_ _F_O_R_M_G_E_N_ B.2

Key: = Function: = Command:

m_ ESC = ESCAPE = ESC
= WORD RIGHT = @F
= TABULATION = @I (SHIFT + )
= WORD LEFT = @A
RUBOUT = DELETE CHARACTER LEFT = DEL
CLEAR = NOT USED =
= NOT USED =
PA1 = SET/CLEAR TAB = @U
PA2 = INSERT COL = @B
PA3 = DELETE COL = @T
PA4 = FORM DONE = @C
PA5 = SAVE AND EXIT = B
= CURSOR UP = @E
= CURSOR DOWN = @X
= CURSOR LEFT = @S
= CURSOR RIGHT = @D
PF1 = DELETE CHARACTER = @G
PF2 = DELETE FIELD = @Z
PF3 = DELETE LINE = @Y
PF4 = INSERT HOLE = @V
PF5 = DEFINE FIELD = @R
PF6 = DEFINE KEY = @K
PF7 = PRINT FORM = @W
PF8 = HELP = @J
p_ = CARRIAGE RETURN = CR

F_
\f

«eof»

DataMuseum.dk

CP/M

⟦8ee76ce00⟧ TextFile

Derivation

TextFile