top - download
⟦f9579ad61⟧ Wang Wps File
Length: 13071 (0x330f)
Types: Wang Wps File
Notes: Spelunked
Names: »~ORPHAN39.12«
Derivation
└─⟦b3c9a9699⟧ Bits:30006142 8" Wang WCS floppy, CR 0015A
└─ ⟦this⟧ »~ORPHAN39.12«
WangText
FIGURE 3.4.2.1-1
CPIP INTERFACE OVERVIEW…86…1 …02… …02… …02… …02…
3.4.2.2 F̲o̲r̲m̲a̲t̲ ̲o̲f̲ ̲A̲M̲O̲S̲ ̲M̲e̲s̲s̲a̲g̲e̲/̲A̲n̲s̲w̲e̲r̲ ̲t̲o̲/̲f̲r̲o̲m̲ ̲C̲P̲I̲P̲
Message from CTERM requesting despatch of control messages.
Message Answer
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^̲ ̲Type = 0 ̲^̲ Word 0 ^̲ ̲ Type = 0 ̲^̲
^̲ ̲Message type ̲^̲ 1 ^̲ ̲ Message type ̲^̲
^̲ ̲Channel no. ̲^̲ 2 ^̲ ̲* Channel no. ̲^̲
^̲ ̲ ̲^̲ 3 ^̲ ̲ ̲^̲
^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ 4 ^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲
M̲e̲s̲s̲a̲g̲e̲ ̲t̲y̲p̲e̲
1 : Message ACK
2 : Message NACK
3 : Open Link Request
6 : Close Link
* Only at dispatch of ACK/NACK-then channel no of
which ACK/NACK shall be performed.
Messags from CTERM about reception of control messages.
Message Answer
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^̲ ̲Type = 1 ̲^̲ Word 0 ^̲ ̲ Type = 1 ̲^̲
^̲ ̲Mesage type ̲^̲ 1 ^̲ ̲ Message type ̲^̲
^̲ ̲Channel no. ̲^̲ 2 ^̲ ̲ Channel no. ̲^̲
^̲ ̲ ̲^̲ 3 ^̲ ̲ ̲^̲
^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ 4 ^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲
M̲e̲s̲s̲a̲g̲e̲ ̲T̲y̲p̲e̲
1 Message ACK
2 : Message NACK…86…1 …02… …02… …02… …02…
3.4.3 C̲P̲I̲P̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
3.4.3.1 C̲P̲I̲P̲ ̲M̲a̲i̲n̲ ̲F̲l̲o̲w̲ (ref. fig. 3.4.3.1)
The CPIP passes through an initializing phase. After
this events to initiate some kind of processing is
awaite. They may be:
1) Despatch of a narrative message from FIKS to CCIS.
This is realized as an entry in the CPIP-queues.
I.e. an AMOS- signal sent to CPIP (an AMOS-signal
is also sent to CPIP when FIKS-CCIS Link is opened)
or transmission of a previus sent message (narrative/control)
is completed.
2) Despatch of a control message from FIKS to CCIS.
This is initiated by sending an AMOS message to
CPIP or by completion of a previously sent control
message.
3) Despatch completed. I.e. the CNS has despatched
all packets belonging to a message and returns
this event to CPIP as an answer on the former AMOS-
message sent to CNSS (the despatch command). It
is now time to start the ACK/NACK monitoring.
4) Arrival of an ACK/NACK. This even is noted as an
AMOS message sent from CTERM. A new message may
be despatched.
5) ACK/NACK timeout. An expected ACK/NACK has not
been received within a certain time limit. This
may be caused by a breakdown in the FIKS CCIS Link.
6) Keep Alive Tmeout. No traffic has passed the link
within a certain limit. A 'Keep Alive' control
message is sent to CCIS in case the CCIS Link is
open.…86…1 …02… …02… …02… …02…
FIGURE 3.4.3.1-1
CPIP MAIN FLOW…86…1 …02… …02… …02… …02…
3.4.3.2 C̲P̲I̲P̲ ̲T̲i̲m̲i̲n̲g̲ ̲C̲o̲n̲t̲r̲o̲l̲
To control the timing in the CPIP- Process (ACK/NACK-
timeout, KEEP ALIVE- timer), the AMOS SETCYCLE/ZEROPHASE-
event is used (ref. 1.3.(27 + 28).
CCLE is set to be one second. The timers/timeouts are
controlled by decrementing those with CYCLECOUNT (i.e.
no. of seconds) each time a timeout event occurs. The
timeout is awaited by using MON (WAITEVENT, BMDELAY
part of event mask, DELAY = minimu of timeouts). The
actual time consumption is achieved by getting the
CYCLECOUNT by the use of MON(WAITEVENT, BMZEROPHASE
equal event mask).
The timers are started/dismanteled by setting them
to timeout size/-1.…86…1 …02… …02… …02… …02…
3.4.3.3 C̲P̲I̲P̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲i̲n̲g̲
As the FIKS MTCB/QACCESS- Monitors are going to be
used MTCB ̲INIT is performed. ref. (1.3.29 + 1.3.30).…86…1
…02… …02… …02… …02…
3.4.3.4 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲o̲f̲ ̲N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
(ref. fig. 3.4.3.4)
The following shall be fulfilled before a narrative
message is despatched to CCIS.
- The FIKS CCIS Link must be opn.
Checking for this is performed by inspection of
CCIS ̲STATUS in the Critical Region CONFIG. (ref.
sec. 3.1.1.4)
- Neither the narrative or the control channel must
be ACTIVE (I.e. a transmission has been started
and not yet finished). When a essage is despatched,
the corresponding channel is set ACTIVE and remains
ACTIVE until ACK/3(NACK's/timeouts) is received.
A checking for 'Too low user classification' is performed.
The CCIS- classification is fetched from the terminal
control blck (TCB, ref. 1.3.6, sec. 7.2) and compared
to that of the message going to be despatched. This
one is fetched from the MTCB referring to the message.
If this one is greater than the first one, then the
message is 'distributed' to the supervisor asfollows:
A pseudo MTCB with layout as in ref. 1.3.6, sec. 7.1.2.14-4
and subcategory 'Terminal has too low classification'
is created, filled, updated and enqueued into the supervisor
DT-queue. Checkpointing of the event is also performed.
No furher processing concerned the message is carried
out.
Before the message is despatched to CCIS, it is edited
to fulfil the format specified in sec. 3.1.1.2. This
is performed as follows:
- A new MTCB is created
- A PDB- file belonging to the MCB is created
- The message until the address list is transferred
to the PDB-file. Binary header is updated - address
list off-set + message length is incremented with
that corresponding to 'SIGNAL' - tail ref. 3.1.1.2.
- 'SIGNAL' - tail, i.e Rlease- and Retrieval time
are added to the file in the same way as when the
FIKS PIP- process is printing the same text lines.
ref. 1.3.17, sec. 3.4.3.2.
- The address list is added to the file.
- The new MTCB is updated as a copy of the old one
except for LENGTH, HDB ̲ADDRESS and HDB ̲MARK. (ref.
1.3.6, sec. 7.1.1.1).
Despatch t CNSS is performed. I.e. an AMOS- Message
as defined in sec. 3.4.2.2 is sent to CNSS.
The event of despatch, to CNSS is logged by using the
'Message Journal'- Monitor with event code 'PRINT STARTED'
ref. 1.3.21.
CPIP Status is set to 'NARRATIVECHANNEL ̲ACTIVE' and
KEEP ̲ALIVE ̲TIMER is dismantled.
N̲o̲t̲e̲: No deletion from CPIP-queues or checkpointing
is performed.…86…1 …02… …02… …02… …02…
FIGURE 3.4.3-4
PROCESS NARRATIVE MESSAGE FLOW…86…1 …02… …02… …02… …02…
3.4.3.5 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲o̲f̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
(ref. fig. 3.4.3.5)
The Control Channel must not be ACTIVE at despatch
of control messages.
The ACK/NACK has the highest priority of allcontrol
messages. This is handled by scanning the CPIP-AMOS-message
event queue before each despatch.
This is performed by using MON(INSPECTEVENT), MON(SAVEEVENT),
MON(RECOVERENENTS), ref. 1.3.29. If an ACK/NACK is
found then this one is dispatche.
The CPIP itself creates the control message. I.e.:
- A MTCB is created
- A PDB-file belonging to the MTCB is created
- The message is filled into the PDB-file with the
layout as stated in sec. 3.1.1.2.
- The MTCB is filled and updated n accordance with
the specifications given in sec. 3.2.2.2.
Dispatch to CNSS is executed. I.e. an AMOS-message
as defined in sec. 3.2.2.2 is sent to CNSS.
The CPIP status is set to 'CONTROL ̲CHANNEL ̲ACTIVE'
and KEEP ̲ALIVE ̲TIMER dismantled.…86…1 …02… …02… …02…
…02…
FIGURE 3.4.3-5
PROCESS CONTROL MESSAGE FLOW…86…1 …02… …02… …02… …02…
3.4.3.6 A̲C̲K̲/̲N̲A̲C̲K̲ ̲-̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲
The ACK/NACK timeout counter (ref. sec. 3.4.3.2) is
set when despatch completion is returned from CNSS.
At reception of ACK/NACK notice, the coresponding channel
is set not ACTIVE and ACK/NACK timeout counter is dismantled.
If one of the channels (the narrative) is still ACTIVE,
then the counter is reset. (The narrative channel has
been interrrupted of a control message and ACK/NACK-
timeot is restarted).
If ACK on the narrative channel is received, then the
entry in the CPIP- queue is checkpointed deleted (ref.
1.3.6, sec. 8.1.4.1) and afterwards the entry is actually
deleted together with releasing the MTCB/PDB- file
of the editd message by the use of MON(MTCB/QACCESS)
- calls (ref. 1.3.29, 1.3.30)
ACK on the control channel causes release of the corresponding
MTCB/PDB-file.
At reception of NACK or ACK/NACK-timeout the NACK-
counter is incremented. If the counter is lss than
3, then the message concerned is repeatedly despatched.
If equal 3 the FIKS CCIS Link is assumed to have FAILED.
Then the CCIS ̲STATUS in the critical region CONFIG
is set to CLOSED (ref. sec. 3.1.1.4) and a report 'FOD
CCIS FAILURE' is sentto the supervisor by the use of
the SEND ̲REPORT- monitor procedure (ref. 1.3.22).
The CNSS-process is notified of the event via an AMOS-signal.
The CNSS will then perform (or attempt to) link recovery,
ref. sec. 3.2.3.5.
3.4.3.7 K̲e̲e̲p̲ ̲A̲l̲i̲v̲e̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲
Whenever a message is dispatched, the KEEP ̲ALIVE-timer
is started, (possibly dismantling the old one).
If the timer runs out and the FIKS CCIS ink is open,
then a KEEP ̲ALIVE control message is created and despatched
to CCIS, as if it was an ordinary control message.
A breakdown in the FIKS CCIS Link will then also be
discovered and reported in the usual manner, even if
no narrative traffi is going on.…86…1 …02… …02… …02…
…02…
3.4 C̲P̲I̲P̲ ̲E̲r̲r̲o̲r̲ ̲L̲o̲c̲a̲t̲i̲o̲n̲s̲
3.4.5 C̲P̲I̲P̲ ̲N̲o̲t̲e̲s̲
S̲t̲o̲r̲a̲g̲e̲ ̲A̲l̲l̲o̲c̲a̲t̲i̲o̲n̲:
The CPIP-process has the following memory claim (approximately)
in words:
Program: 1090
Process: 1000
P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲:
he CPIP is very suitable for being executed as 'Background
Task'. The size of program/process is less than required.
Ref. 1.2.28, sec. 3.3.15.
P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲f̲o̲r̲ ̲D̲e̲l̲i̲v̲e̲r̲y̲:
Do as stated in the file 'INFORMATION' in the last
delivery of CPIP to FIXIB. Ref. 1.3.34.
M̲o̲d̲u̲l̲e̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲:
The CTERM-module is compiled and linked by means of
the AMOS SWELL Compiler and Linker. Ref. 1.3.35/36/37/38.…86…1
…02… …02… …02… …02…
3.5 C̲C̲I̲S̲L̲T̲U̲X̲
The CCISLTUX is implemented by means of the LTUX-M
System as described in ref. 1.3.20. I.e. one CCISLTUX
consists of two HW-modules:
- LTUX-M-FE. This device makesup the front-end processor
for data packets passing between the FIKS TDX-system
and the CR80 computer.
- LTUX-M-CPU. This module constitutes the X25 HDLC/LAPB
protocol machine and interface to FODCCIS.
The two modules communicate with each othe via a separate
micro-bus. The V24-connection to FODCCIS is performed
through jack 1 of the back panel (type BP5). Switching
between use of external/internal transmit clock (modem/no
modem interface) is performed by removing/insertion
of jumber SR2. The CCISLTUX environment overview is
shown in fig. 3.5.1.
The interface between the CCISLTUX and the rest of
the FIKS system is described in ref. 1.3.13 and 1.3.23.
The CCISLTUX is procured as follows:
- As basis HW-modules the
LTUX-M-FE Module P/N: 4.04133-03
LTUX-M-CPU, Module P/N: 4.04143-04
are employed. (The modules are those used at the
LME + NAM applications).
- The TDX-system FW (in the LTUX-M-FE) is exchanged
with the version identical to that used in other
FIKS TD-devices.
- The LTUX-M-FE/LTUX-M-CPU interface FW is updated
to reflect the changed SHARED RAM allocation (in
relation to other FIKS usages).
The X25 HDLC/LAPB FW (ref. 1.3.14) is placed in
the LTUX-M-CPU.
- The RAM placed in the LTUX-M-CPU osition UG3 is
not needed, i.e. can be removed.
- Jumpers (straps) and dil-switches are set in accordance
with the application requirement.
I.e. the CCISLTUX can be procured on basis of exisitng
CR-modules without performing any irreversible HWinterference.
Figure 3.5-1
CCISLTUX Environment Overview…86…1 …02… …02… …02… …02…
The actual set-up of the modules is specified in a
'FIKS FIRMWARE RELEASE'-note, i.e. a DCN to ref. 1.3.40.
All sources and object codes concerned the used firmware
can be foundin and obtained from the
SE-VAX-A MIJ.X25LTUX - and
SE-VAX-A MIJ.MCPU - directories.
The firmware is placed in EPROM's as follows:
C̲R̲ ̲P̲R̲O̲M̲ ̲N̲o̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲P̲R̲O̲M̲ ̲T̲y̲p̲e̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲A̲d̲d̲r̲e̲s̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲P̲l̲a̲c̲i̲n̲g̲
̲ ̲
2825 2716/2516 0000-07FF LTUX-M-FE
2826 2732/2732A 4000-4FFF LTUX-M-FE
2827 2532 0000-0FFF LTUX-M-CPU
2828 2532 1000-1FFF LTUX-M-CPU
2829 2532 2000-2FFF LTUX-M-CPU
2830 2732/2732A 3000-3FFF LTUX-M-CPU
Master-copies
