⟦7d9cb1e27⟧

TextFileVerbose

>fo RCSL 52-AA 1035~LEC RC3500 SOFTWARE REVISION 3~PROG. GUIDE
>a1 INTRODUCTION
This programming guide describes the RC3500 part
of the DQ system software,
as installed at Michigan Bell Telephone Company,
during spring 1981.

The intention is that the programming guide should give an overview of
how the RC3500 software is structured,
i.e. how the different software modules
share the work amongst them.

For some of the modules,
more detailed information is given.
The reason for this may in each case be one of the following:

>in 3
>ti-3
1.@Another version of the module is used than the version
for which a software description exists.

In this case the differences from the old version are described.

>ti-3
2.@Some facilities in the module is specially important.

In this case these facilities are described.

>ti-3
3. No software description exists for the module.

In this case a preliminary software description
is given here.
>in-3
>a1 RC3500 SOFTWARE STRUCTURE
The RC3500 software system is based on the CATS35 network system
with ISO 7-bit character code.

The software modules of the RC3500 DQ-system
may be separated in two sections,
a net system and a front end system.

>ul
The@net@system
contains modules which can be divided into two groups:

>in 3
>ti-3
1. A CATS35 primary center
>sp 0
performing the routing of data and the connection
to the communication lines.

>ti-3
2. A CATS35 secondary center
>br
containing modules
acting as concentrators and supervisors of the DQ-terminals.
>in-3

>ul
The@front@end@system
consists of program modules, which
 
>in 3
>ti-3
1.@take care of the communication with the hosts (RC8000's),
i.e. supervise the main consoles of the hosts and
the programming terminals,

>ti-3
2.@distribute data to the hosts, and

>ti-3
3.@take care of the operator messages
printed on the RC3503 status printer.
>in-3
 
The RC3503 Front End Processor (FEP = RC3503 A)
contains both a net system and a front end system.
The other RC3500's/RC3503's contain the net system only.

>a1 THE NET SYSTEM
The net system is constituted by the program modules
illustrated on fig. 1.
>ne 44
>sp 42
>fg The program modules of the net system

The boxes each illustrate one program module.
A box with a "shadow" indicates that more incarnations
of the module may exist in the RC3500/RC3503 in question.

In the following each program module of the net system
is described.
>a2 NCC2
NCC2, the Network Communication Controller,
is the heart of the net section.
All messages pass this module,
which determines what to do, and transmits the messages
to the next module
on their way to the destinator.

>a3 Changes from NCC1
NCC2 is equivalent to NCC1 (ref. RCSL 52-AA@194)
with the following exceptions:

>in 3
>ti-3
1.@The testing facilities, "trace" and "show",
have been removed.

>ti-3
2.@The NSS-semaphore (e2) can now be set to 0.
The result of this is,
that an operation with a syntax-error in it
will be treated as an empty buffer.
To investigate the syntax error in a testsituation
you should know that a "sub@w0@i@2" instruction
has been placed at the address pointed out by
the text "message@ncc@checkpoint" in the listing.

>ti-3
3.@If the status bit 5 is set
(i.e. op.j13
>ul
and
32 = 1),
the receiver name and the sender name will be exchanged
before the name table is searched.

>ti-3
4.@A semaphore address in the name table can be set to 0, too.
If NCC2 finds an entry like this,
it will act as if the name were not in the table
and the message will be nak'ed.
This facility is now extended to apply the last entry
of name table, too,
i.e. if the semaphore address connected to the last entry is
>ul
different@from
0, the received message will be sent to the stated semaphore
with the local index stated.

>ne 6
Notice, that the last entry must have the same format
as the other entries,
i.e. 

   4 bytes for the name (to be inserted by NCC)
   2 bytes for the local index
   2 bytes for the semaphore address.

>ti-3
5. The release of empty buffer operations is executed
by means of the procedure "return@empty@op",
ref. Monitor.ext (h24).

>ti-3
6. The buffer distribution list must hold
the size of the buffer:

   <owner sem> <no of buffers> <size of buffers>

>ti-3
7. Buffers are distributed by means of the procedure
"reserve buffer", ref. Monitor.ext (h23).
Notice, that this version of reserve buffer
uses the procedure "reserve space",
ref. Monitor.ext (h17).

>ti-3
8.@If the "nak reduction" parameter (e11) is positive,
the nak'ed buffer text will be reduced
to the size which e11 indicates:

   op.j12 := op.j14 + CATS35 header (incl. STX)

           + e11 + 2

(as op.j12-1 wil be overwritten with ETX).

>ti-3
9.@The name table has been extended,
so that it now has both a local and a global part.
The local part is equivalent to the NCC1 table.
The global part has the same structure as the local part,
but only agreement on the first letter is checked,
i.e. all remote addresses are placed in this part of the table.
The tables must be placed in continuation of each other,
with the local part as the first one.

>ti-4
10.@NCC2 handles the "global table" different than NCC1.
Searching in the name table is equivalent,
but instead of checking if the name agreement
is found in the last entry or not,
NCC2 will check if the semaphore address equals 0.
If it equals 0, NCC2 acts similar to NCC1,
finding agreement in the last entry.
If different from 0,
NCC2 treats it like a normal entry.
>in-3
>np
>a2 NSS1
NSS1, the Network Status Supervisor,
takes care of messages containing syntax errrors
and messages with an unknown receiver.
>a2 HICC2
HICC2, the HIgh level Communication Controller,
is responsible of the communication protocol
carried on with the LOCC in the neighbouring RC3500/RC3503.
>a3 HICC2 Addressing Algorithm
From revision 2 to revision 3
the LEC 3500 software has been improved
by implementing an "addressing algorithm" in the HICC2-module.
The use of this algorithm implicates,
that you do not need to generate special software for each node
(i.e. each RC3500/RC3503 machine)
in the cluster.
In the revision 3 software the nodes, namely,
do no longer carry each their own identification code.

The problem of deciding where to send the answer of a message
from a DQ-terminal,
is solved in another way:

The route which a message follows,
after it has been input by a DQ-terminal,
is "built" into the
>ul
sender@name
on the way to the front end machine.
When the message answer is being output,
the HICC-module in each node on the way
extracts the next step of the route
(the local index)
from the
>ul
receiver@name.

The exact algorithm is:

>ne 14
>ul
Input-op:

       x := (y - 65) * 16 + index + 66

where:

 y     is (the ISO-value of) the first letter
       of the receiver

 index is the number of the communication line
       over which the message came to the node

 x     is the transformed first letter of the
       receiver

>ne 13
>ul
Output-op:

       x := (y - 66) div 16 + 65

       index := (y -66) mod 16

where:

 y     is the first letter of the sender

 index is the number of the communication line to use

 x     is the transformed first letter of the sender

Notice, that a message is transformed every time it passes
a communication line (BSC or GCI),
namely by the HICC-module controlling that line.
On the other hand there is no address transformation going on
in the node holding the DQ-terminal
(the DQ-terminal is not connected via a HICC).

Notice also, that using this algorithm
a message (the input-op)
and the corresponding message answer (the output-op)
will use exactly the same communication lines,
even if more than one physical route is possible.

The node identification letters used on the node description
(ref. RC3500 Software, rev. 3, Release Information)
is determined by the addressing algorithm.
The number corresponding to the letter in the IS0 system,
is, namely, the result of the HICC-transformations,
which a message will go through on its way to the front end
(the start sender letter is an "A" no matter from
which DQ-terminal the message originates),
presumed you take the communication line between level 1
and level 2 with the
>ul
even
number.

All nodes on level 2 and 3 have, due to this algo- rithm,
got two different internal identifications.
The hosts will get a unique identification
of a remote terminal, though, due to some changes
in the OPA and COM35 modules.

The algorithm can be used
if the number of levels do not
exceed 3,
if the number of lines from level 1 (the front end)
to level 2 does not exceed 15,
and if the number of lines from each CON-machine (level 2)
to level 3 do not exceed 2.

One major problem of adding more levels or more lines is,
that any letter actually produced in the algorithm,
does have to be represented in one byte,
which implies that only values in the range 0 through 127
is allowed (the 8th bit of the byte is a parity bit).
>a2 LOCC2
LOCC2, the LOw level Communication Controller,
is a slave of the HICC in the neighbouring RC3500/RC3503,
and services the "low" end of the communication line.
>a3 Changes from LOCC1
LOCC2 is equivalent to LOCC1
(ref. RCSL 52-AA@191)
with the following exceptions:

>in 3
>ti-3
1.@In the LOCC1 system every coroutine has its own
pool of buffers,
and operations from NCC can only be handled
of a predetermined LOCC coroutine.

In the LOCC2 system all the coroutines share one buffer pool.
Operations from NCC go to a shared queue,
and they may thus be handled of different LOCC2 coroutines:
The coroutine that is ready for handling the operation firstly,
gets it and takes care of it.

>ti-3
2.@With the changes above,
up- and down-messages from the LOCC are no longer necessary,
and are thus left out.
>in-3
>a2 BSC
BSC, the Block Synchronous Controller driver,
is the driver of the BSC100 interface.
>a2 GCI
GCI, the General Controller Interface driver,
is the driver of the GCI100 interface.
>a2 MTC2
MTC2, the Multi Terminal Controller,
is the concentrator of the DQ terminals.
>a2 OP2
OP2 (or LECOP2), the DQ terminal supervisor,
manages the DQ-terminals.
The OP2-module includes the terminal drivers.
>a2 MIRROR
MIRROR is a module which may be included in the net system
for test purposes.
If included (i49>0) you can direct messages to it
by changing a semaphore address in the NCC1 name table
or in the MTC1 terminal list to the MIRROR semaphore address.

All messages which are meant for the semaphore,
will now be directed to the MIRROR module.

The MIRROR module will now act as a "mirror" for
an arriving message.
It will just swap the receiver name with the sender name,
and thus return the message unchanged to sender.

With a MIRROR module active in two machines,
you can in this way simulate heavy traffic
over one or more communication lines.



>a1 THE FRONT END SYSTEM
The front end system is constituted by the program modules
illustrated in fig. 2.
>ne 44
>sp 42
>fg The program modules of the front end system

In the following the program modules,
illustrated by the boxes,
is described.
>a2 OPA
OPA (or LECOPA), the enquiry OP Adaptor,
receives messages from DQ-terminals
and distributes them to COM35 and the hosts.
The receiver host is found as a function
of the messages and the traffic to the hosts.
Reverse is the answer from the hosts passed on to the NCC.
>a3 Unique terminal id's to RC8000
The HICC2 addressing algorithm
(ref. section 3.3.1)
makes all remote DQ-terminals have two names
in the CATS35 network.
The RC8000 hosts want unique names, though.
Therefore the OPA-module has been changed to ensure this.

The idea is, that the OPA module knows,
that the two possible identifications only differ
on the first character,
and this character is one out of two characters,
which are placed beside each other in the ISO scheme.

When OPA receives an input message from NCC,
it will make the first sender charcacter even.
When OPA, on the other hand,
receives an output message from a RC8000 host,
it will reestablish the character
(from the ips-element where it was saved)
before the answer is passed on to NCC.
>a2 COM35
COM35, the update COMmunication module of RC3500,
receives data base update messages from the OPA
and broadcasts them to all the hosts (RC8000's).
The first received answer from the hosts to the
current DQ-terminal is passed on to the NCC
and the answers from the remaining hosts are dropped.
>a3 Unique terminal id's
The COM35 module has been changed for the same reason as OPA.

When a broadcast operation is received,
the first sender char is made even.
The original character is saved in the com-header.type byte
in the missing answer queue element.
When the answer from the first RC8000 host arrives,
the character is re_estab_lished,
before the answer is passed to NCC.
>a2 SSP
SSP, the System Status Printer coroutine,
manages the status messages received from the other modules
and the printing on the physical status printer.
>a2 MUX
MUX, the software MUltipleXer,
is the software interface between the LTD's
and the low speed asynchronous multiplexer.
>a2 LTD
LTD, the LAM Terminal Driver,
is a channel driver of the MUX.
It manages the teletype compatible devices,
i.e. the main consoles,
the Ontel programming terminals
and the status printer.
>a2 GDI
GDI, the General Driver Interface,
is a software module to supervise the drivers.
>a2 BBM
BBM, the Battery Backup Memory driver,
is the driver of the BBM100 interface.
>a2 VTC
VTC, the V24 Terminal Controller,
takes care of the communication between the DHC
and the programming terminals
including the main consoles.
>a2 DHC
DHC, the Device Host Controller,
controls the links between the hosts and the OPA,
COM35, the main consoles and the programming terminals.
>a2 RCH
RCH, the RC8000 Host controller,
takes care of the protocol used in the communication
between the hosts and the front end.
The module includes the RCD.
>a3 RCH Buffer Sizes
The buffers used in RCH for RC8000 output
are placed in queues with two different sizes,
a "max size" and a "half size".
The buffers are distributed in the standard queue LBQ
(max size buffers)
and the special queue LEC
(half size buffers)
in the ratio of (1 + no of hosts) to (2 * no of hosts).

When RCH receives information of buffersize from RC8000,
it checks if a LEC buffer will do and if one is available.
If so, a LEC buffer is allocated and loaded.
If not, RCH will try to allocate a LBQ buffer
(similar to the old software where only LBQ buffers existed).
>a2 RCD
RCD, the RC8000 Driver,
is the FPA interface to the RC8000 host.
The module is included in the RCH module.
>a1 REFERENCES
>ti-8
LEC@SW@@LEC RC3500 SOFTWARE, rev. 3, Release Information,
>sp 0
RCSL 52-AA@1027.

MULTI RC8000 DQ SYSTEM, Operating Guide,
>sp 0
RCSL 52-AA@1026.

>ti-8
RC3500@@RC3500 Reference Manual, RCSL 52-AA@021.

RC3500 General Information, RCSL 52-AA@059.

>ti-8
RC3503@@RC3503 Reference Manual, RCSL 42-i 1540.

RC3503 General Information, RCSL 52-AA@1013.

>ti-8
MONITOR RC3500 Monitor 1, RCSL 52-AA@187.

RC3500 Monitor 1.1, RCSL 52-AA@956.

Monitor ext. TSR, 80.07.21, Danish language.

>ti-8
DEBUG@@@RC3500 Debug 1.0, RCSL 52-AA@186.

>ti-8
CATS35@@CATS35, General Description. RCSL 52-AA@188.

>ti-8
HICC@@@@CATS35 Module Description of HICC1, RCSL 52-AA@190.

>ti-8
LOCC@@@@CATS35 Module Description of LOCC1, RCSL 52-AA@191.

>ti-8
MTC@@@@@CATS35 Module Description of MTC1, RCSL 52-AA@193.

>ti-8
NCC@@@@@CATS35 Module Description of NCC1, RCSL 52-AA@194.

>ti-8
BSC@@@@@CATS35 Module Description of 48k-baud-BSC-driver,
RCSL 52-AA@203.

RC35-108 Block Synchronous Communication Controller,
General Information, RCSL 52-AA@751.

>ti-8
TEST810 CATS35 Module Description of TEST, RCSL 52-AA@205.

>ti-8
SSP@@@@ CATS35 Module Description of SSP1, TSR / June 1980.

>ti-8
MUX@@@@ RC35-103/104 LAM MULTIPLEXER Software Description,
RCSL 52-AA@225.

>ti-8
LTD@@@@ RC35-103/104 LAM TERMINALDRIVER Software Description,
RCSL 52-AA@228.

>ne 2
>ti-8
GCI@@@@ General Information for RC35-210 interface,
>sp 0
RCSL 52-AA@309.

>ti-8
RCNET@@@RCNET includes the modules DHC, RCH, VTC and others.

RCNET General Description. RCSL 52-AA@574.

RCNET Formats and Tables, RCSL 52-AA@575.

>ti-8
DHC@@@@ DHC Software Description, RCSL 52-AA@576.

>ti-8
RCH@@@@ RCH Software Description, RCSL 52-AA@577.

>ti-8
VTC@@@@ VTC Software Description, RCSL 52-AA@578.

>ti-8
OPA@@@@ CATS35 LECOPA Programmer's Guide, RCSL 52-AA@924.

>ti-8
COM35@@ COM35 Programmer's Guide, RCSL 52-AA@941.

>ti-8
GDI@@@@ GDI1 - COROUTINE, RCSL 52-AA@949.

>ti-8
BBM@@@@ RC3500 - BBM100 Driver, RCSL 52-AA@950.

BBM100 Programmer's Reference Manual, RCSL 52-AA@880.
«eof»
DataMuseum.dk

RC3500

⟦7d9cb1e27⟧ TextFileVerbose

Derivation

TextFileVerbose
