top - download
⟦ce8c4ed79⟧ Wang Wps File
Length: 43865 (0xab59)
Types: Wang Wps File
Notes: PIP SUBSYSTEM PSP
Names: »3054A «
Derivation
└─⟦dfa2fde64⟧ Bits:30006137 8" Wang WCS floppy, CR 0266A
└─ ⟦this⟧ »3054A «
WangText
…1d……00……00……00……00…7…02……00……00…7
7…07…6…0b…6…0d……15……09……15……0d……15……00……15……02……15……06……14……09……14……0c……14……0f……14……02……14…
…14……06……13……08……13……0a……13……0d……13……00……13……01……13……05……13……07……12……0a……12……0e……12……01……12…
…12……06……11……09……11……0c……11……86…1 …02… …02… …02…
…02…FIX/1152/PSP/0075
…02…APE/821108…02……02…#
PIP SUBSYSTEM PSP
…02……02…FK 7809
Li̲s̲t̲ ̲o̲f̲ ̲C̲o̲n̲t̲e̲n̲t̲s̲ P̲a̲g̲e̲
1. SCOPE 1
1.1 Introduction 1
1.2 Abbreviations 1
2. APPLICABLE DOCUMENTS 2
2.1 System Software 2
2.2 FIKS Documentation 3
3. MODULE SPECIFICATION 5
3.1 Functional Capabilities 5
3.2 Interface Description 7
3.2.1 General Description of the Interface 7
3.2.2 Format of AMOS Message/Answer to/from PIP 11
3.3 Processing 15
3.3.1 PIP Main Flow 15
3.3.2 PIP Initializing 17
3.3.3 Activating Events 18
3.3.3.1 Signals 18
3.3.3.2 Logon/Logoff-messages 19
3.3.3.3 Print Request (Teleprinter) 20
3.3.3.4 Special Handling Printrequest 20
3.3.3.5 TIMER-answer 21
3.3.3.6 IO-Completion 22
3.3.4 Sequence Initializing 23
3.3.5 Sequences 25
3.3.5.1 Narrative Messages 26
3.3.5.2 Transaction Log 28
3.3.5.3 Message Journal 29
3.3.5.4 Message Log 30
P̲a̲g̲e̲
3.3.5.5 Coordination Printout 31
3.3.5.6 Remarks 32
3.3.5.7 Messages in Preparation 33
3.3.5.8 Special Handling Printout 34
3.3.6 Sequence Finish 35
3.3.7 Common Routines 36
3.3.7.1 Reading of Files 36
3.3.7.2 Formatting of TEXT-BUFFER 38
3.3.7.3 Printing of TEXT-BUFFER 41
3.3.7.4 Check of Classification 44
3.3.8 Error Handling 45
3.3.9 Checkpointing 47
3.4 Data Organization 48
3.4.1 External Data Structures 49
3.4.2 Internal Data Structures 50
3.4.3.1 Page Format 52
3.4.3.2 Acceptance & Retrieval -DTG Format 54
3.4.3.3 Coordination Printout Format 55
3.4.3.4 Message Log Format 56
3.4.3.5 Transaction Log Format 57
3.4.3.6 Message Journal Log Format 58
3.5 Storage Allocation 59
3.6 Performance Characteristics 60
3.7 Limitations 61
3.8 Error Locations 62
3.9 Listing Reference 64
P̲a̲g̲e̲
4. QUALITY ASSURANCE 65
4.1 Qualification Tests 65
4.2 Other Quality Assurance Provisions 65
5. PREPARATION FOR DELIVERY 66
6. NOTES 67
6.1 Module Generations 67
6.2 Node/MEDE-versions 68
7. APPENDICES 69
1. S̲C̲O̲P̲E̲
This document is Product Specification for the Printer Interface application software in
the FIKS-system.
1.1. I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The document is made out after the implementation af PIP was done. The document is primary
meant to be used by those who is going to maintain the PIP. Therefore the intension with
this document is to describe the functions and procedures in the PIP-process in general view
and to explain the reasons why they are implemented as they are.
Some procedures which are rather simple and easily can be understood by inspection of source
listings may not be described in every detail. Capital letters have been used to emphasize
keywords used in other documents or in the source listing.
1.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
Refer to FIKS Data Interface Reference FIX/0100/MAN/0004, sec. 1.2
2. A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲.
2.1 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲.̲
1) CR80 AMOS Kernel,
Product Specification, CSS/302/PSP/0008
2) CR80 AMOS I/O System,
Product Specification, CSS/006/PSP/0006
3) CR80 DMA Link Driver,
Product Specification, CSS/006/PSP/0002
4) CR80 AMOS File Management System,
System Product Specification, CSS/920/SPS/0001
5) CR80 AMOS FMS Command Controller,
Product Specification, CSS/920/PSP/0046
6) CR80 AMOS FMS Disk Cache Manager,
Product Specification, CSS/920/PSP/0047
7) CR80 AMOS FMS File Manager,
Product Specification, CSS/920/PSP/0048
8) CR80 Disk Driver,
Product Specification, CSS/006/PSP/0005
9) CR80 TDX Driver,
Product Specification, CSS/314/PSP/0013.
2.2 F̲I̲K̲S̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲.̲
10) FIKS System PSP,
FIX/1000/PSP/0038
11) FIKS Data Interface Refference,
FIX/0100/MAN/0004
12) Checkpoint Subsystem,
FIX/1100/PSP/0041
13) Convert DTG Monitor,
FIX/1256/PSP/0039
14) Error Switchover Process,
FIX/1105/PSP/0046
15) LCFH Monitor,
FIX/1256/PSP/0055
16) Log Action Monitor,
FIX/1256/PSP/0056
17) Log Journal Monitor,
FIX/1256/PSP/0057
18) MES Submodule,
FIX/1351/PSP/0060
19) MDS Subsystem,
FIX/1152/PSP/0062
20) MTCB Monitor,
FIX/1256/PSP/0066
21) PURGE Procedure,
FIX/1200/PSP/0077
22) QACCESS Procedure,
FIX/1256/PSP/0078
23) SAF Subsystem,
FIX/1155/PSP/0088
24) Test HDB Monitor,
FIX/1256/PSP/0102
25) TIMER Subsystem,
FIX/1200/PSP/0105
26) SRR Subsystem,
FIX/1153/PSP/0096
3. M̲O̲D̲U̲L̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲.̲
The purpose of the PIP-process is in the Node/MEDE for all terminals to control and make
the following logical printouts.
1. Narrative Messages.
- Printing of ordinary messages at receivers terminal after they have been transmitted
through the FIKS-network.
2. Message in Preparation.
- Listing of messages while they are in the preparation phase at senders terminal.
3. Coordination Printout.
- List of messages prepared at a terminal (the originator) at an other terminal (the
coordinator) together with coordinator identification text and originators remarks.
4. Remarks.
- Coordinators remarks.
- Release remarks.
- Statistics.
5. Message Log.
- A Log of messages newly stored on HDB.
6. Message Journal.
- A logging of message processing.
7. Transaction Log.
- Logging of LOGON, LOGOFF, security interrogation events.
The control functions are concerned about if it is allowed to do the printouts. I.e. the
PIP is responsible for.
1. Printouts is only done at a logged on terminal or when a printrequest is issued.
2. The classifiction of the terminaloperator is high enough.
3. Special handling printouts is finished within a certain limit after they are requested
started.
3.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
3.2.1 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲.̲
Interface Data: ref. (10)
Refer fig. 3.2.1 General View.
S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
1. FMS-system via IO-system
2. TDX-system via IO-system
3. Kernel, use of AMOS-message functions and critical region operations.
F̲I̲K̲S̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
1̲.̲ ̲ ̲U̲s̲e̲ ̲o̲f̲ ̲F̲I̲K̲S̲ ̲m̲o̲n̲i̲t̲o̲r̲
1. QACCESS
2. MTCB
3. CONVDTG
4. LOG-JOURNAL
5. TEST-HDB
6. LCFH
2̲.̲ ̲ ̲U̲s̲e̲ ̲o̲f̲ ̲F̲I̲K̲S̲-̲c̲r̲i̲t̲i̲c̲a̲l̲ ̲r̲e̲g̲i̲o̲n̲s̲
1. CONFIG, Configuration table
2. CLASS1, Classification Text (short)
3. CLASS2, Classification text (long)
4. XTCBCR, Terminal control black.
3̲.̲ ̲ ̲I̲n̲p̲u̲t̲ ̲q̲u̲e̲u̲e̲s̲.̲
Printer queues. I.e. one set of input queues per printer with precedence Z, Y, O, LP,
P, M, R.
O̲u̲t̲p̲u̲t̲ ̲q̲u̲e̲u̲e̲s̲.̲
DT-queue.
PURGE-queue.
4̲.̲ ̲ ̲F̲I̲K̲S̲-̲m̲o̲d̲u̲l̲e̲s̲.̲
1. MDS-process.
MDS enqueing into the printer queues.
2. MES-module.
1. MES enqueing into LP-queue for listing of prepared messages.
2. AMOS-message from MES concerning printrequests (ordinary/special handling). AMOS
answer is returned.
3. ITM-module.
AMOS-message from ITM concerning Logon/Logoff. AMOS answer is returned.
4. CHECKP-process.
Use of AMOS messages/answers when checkpointing.
5. TIMER-process.
Use of AMOS messages/answers at special handling timeout test and delay before recovery.
6. SFS/SAF-modules.
Enqueing into DT-queue.
7. PURGE-process.
Enqueing into PURGE-queue.
8. SRR-process.
Message Log print request enqueued into LP-queue.
9. Journal-process.
Message Journal print request into LP-queue.
10. SEND-REPORT-monitor.
Transaction Log print request into LP-queue.
5̲.̲ ̲ ̲F̲I̲L̲E̲S̲.
1. HDB, IMF- and PDB-files via MTCB-monitor.
2. MLF-file at printout of Message Log.
3. MJF-file at printout of Message Journal.
3.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̲ ̲P̲I̲P̲.̲
The messages send to PIP and answers send from PIP shall observe the following format
M̲e̲s̲s̲a̲g̲e̲s̲
Word 1 Message code
2 Terminal No. = logical no of the
3 affected printer.
4
5
A̲n̲s̲w̲e̲r̲s̲
Word 1 Message code Equal to that in
2 Terminal no. the received
3 message
4
5 Completion code = code describing
how the implied
request completed.
3.2.2.1 L̲o̲g̲o̲n̲/̲L̲o̲g̲o̲f̲f̲ ̲o̲f̲ ̲P̲r̲i̲n̲t̲e̲r̲s̲
When a printer is logged on/off then a message from ITM is issued with message codes as follows:
Logon = 1
Logoff = 2
An answer is returned from PIP with the same format. Completion code is not updated.
3.2.2.2 P̲r̲i̲n̲t̲ ̲R̲e̲q̲u̲e̲s̲t̲ ̲f̲r̲o̲m̲ ̲T̲e̲l̲e̲p̲r̲i̲n̲t̲e̲r̲
Prior to printout on a teleprinter, in RXTX mode, the PIP shall receive a message from MES
with
m̲e̲s̲s̲a̲g̲e̲ ̲c̲o̲d̲e̲ ̲=̲ ̲4̲.
An answer is returned. The possible completion code can be:
0: Printout is finished
1: Printout refused due to no queue entry
2: Printout refused due to too low terminal classification.
3.2.2.3 P̲r̲i̲n̲t̲ ̲r̲e̲q̲u̲e̲s̲t̲ ̲o̲f̲ ̲S̲p̲e̲c̲i̲a̲l̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Prior to printout of a special handling message, PIP shall receive a message with
m̲e̲s̲s̲a̲g̲e̲ ̲c̲o̲d̲e̲ ̲=̲ ̲5̲,̲
from MES indicating that the special handling authentication procedure succeded.
An answer is returned. The possible completion codes can be:
0: Printout is finished
1: Printout refused due to no queue entry
2: Printout refused due to too low terminal classification
3: Printout refused due to timeout (The time from the request was received by PIP has exceeded
10 min. and the printout has not yet started).
3.3 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
3.3.1 P̲I̲P̲ ̲M̲a̲i̲n̲ ̲F̲l̲o̲w̲
The main processing of the PIP is described in overview in figure 3.3.1.
PIP passes through an initializing phase. After this events delivered by AMOS is awaited.
Those events initialize some kind of printout - a SEQUENCE.
This sequence involves IO-operations. When an IO-operations is started, the processing concerning
the sequence is temporary suspended until the operation terminates. Then the processing is
resumed until a new IO-operation is started etc.
In this way the PIP is able to printout sequences on every printer at the same time without
interferring processing for the different printers.
3.3.2 P̲I̲P̲ ̲i̲n̲i̲t̲i̲a̲l̲i̲z̲i̲n̲g̲
After PIP has been started by the ESP-process the initializing phase is executed. This include:
1. The last used page number is fetched via the checkpoint mechanism. Refer to sec. 3.3.9.
2. Loglines to the VDU-ROP's and teleprinters are created by call of the LFCH-monitor, ref.
(15).
3. A 'clean printer' procedure is executed for every VDU-ROP. This is done to ensure that
any old data in the VDU-LTUX's is squeezed out. It is done by printing binary zeros -
invisible when printed.
A timeout condition when doing this, may be caused by data, originating from other processes,
being 'stucked' in the LTUX. Therefore in this case the dummy print shall be attempted
at least 3 times before give up.
3.3.3 A̲c̲t̲i̲v̲a̲t̲i̲n̲g̲ ̲E̲v̲e̲n̲t̲s̲
3.3.3.1 S̲i̲g̲n̲a̲l̲
An AMOS-signal delivered to PIP will always mean that one or more entries into an empty printerqueue
has been done. Consequently one or more printers not active for the moment may need service.
To be sure that the signal is interpretted correct all possibilities for starting a printout
at every terminal shall be utilized.
3.3.3.2 L̲o̲g̲o̲n̲/̲L̲o̲g̲o̲f̲f̲ ̲-̲m̲e̲s̲s̲a̲g̲e̲s̲
An AMOS-messge in accordance with the layout given in sec. 3.2.2.1 is delivered to PIP.
The PRINTER-MODE is up-dated:
Logon: AUTOMATIC
Logoff: NOT AUTOMATIC
AUTOMATIC means that when an entry into the printerqueues is done, then the corresponding
printsequence will be printed automatically.
The NOT AUTOMATIC mode is used in connection with teleprinters. They need a PRINT-REQUEST
before they start a print sequence.
In case of LOGON it is attempted to start a printout. This will ensure that any message already
in the printerqueues will be printed.
3.3.3.3 P̲r̲i̲n̲t̲r̲e̲q̲u̲e̲s̲t̲
An AMOS-message in accordance with the layout given in sec. 3.2.2.2 is delivered to PIP.
This means that a printout sequence shall be started (or attempted to). The result of this
shall later on be returned.
3.3.3.4 S̲p̲e̲c̲i̲a̲l̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲P̲r̲i̲n̲t̲r̲e̲q̲u̲e̲s̲t̲
An AMOS-message in accordance with the layout given in sec. 3.2.2.3 is delivered to PIP.
This means that a special handling message printout shall be started (or attempted to).
A timer is started by using the TIMER-process - ref. (25). This shall be used to test if
the special handling printout is started within 10 minutes.
The result of how the printout sequence was passed is returned later on.
3.3.3.5 T̲I̲M̲E̲R̲-̲a̲n̲s̲w̲e̲r̲
The only answers that can be delivered to PIP is from the TIMER-process - ref. (25).
These answers will indicate that a timeout condition is fulfilled.
There are 2 cases to consider:
1. Timeout on a special handling printout request. This can be ignorred if printout concerning
the request is started (or finished) else special handling timeout completion is returned
in the answer on the request (ref. 3.3.3.4).
2. Runout of delay in connection with LOCAL-FIX-UP after an error refer to 3.3.8 Error Handling.
3.3.3.6 I̲O̲-̲C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲
When an earlier started IO-operation, ref. sec. 3.3.1, finishes, the information about this
is returned from the IO-system ref. (2).
This includes an operation refference OP-REF, which is used to identify the operation.
Based on the data stored when the operation was started, it is possible to continue processing
for the printsequence, which the operation was part of.
3.3.4 S̲e̲q̲u̲e̲n̲c̲e̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲i̲n̲g̲
When an event, indicating that a printout can be started, occurs -
Signal,
Logon,
Printrequests,
Finish of another sequence,
then the following procedure is followed:
1. It is checked that the printer is available, i.e.
Printer is not already printing (PRINTER-NOT-IDLE)
and
Printer is logged on (VDU-ROP-PRINTER-MODE is AUTOMATIC)
or
Printrequest is received (Teleprinter)
or
Special handling printrequest is received.
If not then the procedure is terminated with cause PRINTER-NOT-AVAILABLE.
2. It is checked if there are any elements in the printerqueues (special handling printqueue)
by attempting to read from the queues. If not, then the procedure is terminated with
cause
NO-QUEUE-ENTRY (Ordinary)
NO-SH-QUEUE-ENTRY (Special Handling)
3. It is checked if the printout is allowed by doing CLASSIFICATION-CHECK, ref. sec. 3.3.7.4.
If not, then the procedure is terminated with cause:
PRINT-NOT-ALLOWED.
If this checking succeeds, then the printout is started and the state of the printer is set
to:
PRINTER-NOT-IDLE.
3.3.5 S̲e̲q̲u̲e̲n̲c̲e̲s̲
The processing in PIP is split into different print sequences reflecting the different functional
capabilities. Which sequence to be executed is determined by the entries in the printerqueues.
These are accessed via the QACCESS-monitor, ref. (22). On basis of the MTCB-index returned
on MTCB is read via the MTCB-monitor - ref. (20).
Depending upon what type of MTCB is read the different sequences is settled. These are described
in the following.
3.3.5.1 N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Printout of narrative messages is started by enqueing a REAL MTCB into the PIP-queues.ref(11),
sec. 7.1.1, case 5,6,12
The classification of the message is found in the MTCB (.CLASS). After having done CLASSIFICATION
CHECK (3.3.7.4) and formatting of HEADER and TAIL (ref. 3.4.3.1) then message file is opened
via the MTCB-monitor.
First part of the message is then read. This part contains a BINARY HEADER, ref. (11), sec.
10.1.2.1, which is not going to be printed. It holds the acceptance DTG used in the printing
of ACCEPTANCE & RETRIEVAL-DTG later on, ref. 3.4.3.2. It also holds the offset to the ANO-list,
which is neither to be printed.
A refference to the MESSAGE ID, which is a part of the SIGNAL-HEADER, ref. (11) sec. 10.4.2.2,
is fetched from binary header.
Via this refference message-id is stored to be used in the MESSAGE JOURNAL-LOG (PRINT-STARTED)
ref (17).
Now the printing can be done. This is started on a new page using the standard routines.
Reading next part of message file inte TEXT-BUFFER (ref. 3.3.7.1) is alternated with printing
the content (ref. 3.3.7.3).
Before each printoperation, it is tested, in case that a HDB-file is used, that the content
still exists. Ref (24).
When the whole message has been printed ACCEPTANCE & RETRIEVAL-DTG is formatted and printed
at the bottom of the last page, ref. 3.4.3.2. Retrieval DTG is fetched from the REAL ̲MTCB
(.WORD6).
3.3.5.2 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲L̲o̲g̲
This sequence is started by an PSEUDO MTCB catogory/subcategory = 3/1 in the LP-queue. ref
(11) fig. 7.1.2.3-1.
This MTCB contains information of eventype, number of affected terminal and USER-ID of involved
user. ref(16).
These items are formatted as stated in sec. 3.4.3.5 - Transaction Log Format. The principles
specified in sec. 3.3.7.2 is used. The DTG is fetched from QACCESS time tag.
No CLASSIFICATION-CHECK is done.
3.3.5.3 M̲e̲s̲s̲a̲g̲e̲ ̲J̲o̲u̲r̲n̲a̲l̲
This sequence is started by a PSEUDO MTCB entry in the LP-queue of category/subcategory=
3/2. ref (11), fig. 7.1.2.3-3.
The classification 'NATO UNCLASSIFIED' is used at CLASSIFICATION CHECK and at HEADER of TAIL-formatting.
The Message Journal File (MJF), ref (11), sec. 11.11 is used to retrieve the earlier done
loggings (MJF-records) from.
The MTCB contains the number of first and last record in the MJF-file, that is to be read,
edit and printed. The records are read into a buffer MESSAGE-JOURNAL-BUFFER (MJB) and formatted
into the TEXT-BUFFER in one operation. This will ensure that the MJB-buffer can be used as
common buffer for all printers.
Only loggings of type 'Message printout strated' is printed.
3.3.5.4 M̲e̲s̲s̲a̲g̲e̲ ̲L̲o̲g̲
This printout sequence is stared by a PSEUDO MTCB entry in the LP-queue of category/subcategory
= 3/3. ref. (11), fig. 7.1.2.3.5.
The classification 'NATO UNCLASSIFIED' is used at CLASSIFICATION-CHECK and at HEADER and
TAIL-formatting.
The Message Log File (MLF), ref (26), is used to retrieve the logging records from.
The MTCB contains the number of records in the file. All these records are read and edit
in accordance to the layout specified in 3.4.3.4. The records are read into a specific buffer
MESSAGE-LOG-BUFFER (MLB) and edit into the TEXT-BUFFER (ref. 3.8.3) in one operation. This
will ensure that the MLB-buffer can be used as common buffer for all printers.
When printout is finished the MESSAGE-LOG-FLAG ref(11), sec. 5.1. is cleared, to enable Message
Log printout at other printers.
3.3.5.5 C̲o̲o̲r̲d̲i̲n̲a̲t̲i̲o̲n̲ ̲P̲r̲i̲n̲t̲o̲u̲t̲
This printout secquence is started by a PSEUDO MTCB of category/subcategory = 4/0 in the
LP-queue. Ref (11), fig. 7.1.2.4-1.
This MTCB contains a MTCB-index referring to a REAL MTCB, which points to a message, that
is in the preparation pool. This message is printed. Before the message text (ref. 3.4.3.1),
a COORDINATORS ̲IDENTITY-text is printed and afterwards a ORIGINATORS ̲REMARK-text is printed
(ref. 3.4.3.3). These texts are read from the MTCB-File associated with the PSEUDO MTCB.
Offsets, lengths of the texts are contained in the PSDEUDO MTCB.
The classification code used at CLASSIFICATION ̲CHECK and formatting of HEADER & TAIL is fetched
from the REAL.MTCB (.CLASS).
When printout is finished the PSEUDO ̲MTCB is updated. (.BYTE1 is sat to 1̲).…86…W …02…
…02… …02… …02…
3.3.5.6 R̲e̲m̲a̲r̲k̲s̲
This printout sequence is started by a PSEUDO-MTCB entry of category = 4/2 in the LP-queue,
ref(11), fig. 7.1.2.4-3.
The content of the MTCB-file, which the PSEUDO-MTCB is pointing at, is printed only using
PAGE-FORMAT. ref(3.4.3.1).
No CLASSIFICATION-CHECK is done.
3.3.5.7. M̲e̲s̲s̲a̲g̲e̲s̲ ̲i̲n̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲.̲
This printout is started by a PSEUDO MTCB entry of category/subcategory = 4/5 in the Lp-queue.
ref.(11), fig 7.1.2.4-6.
This MTCB contains a MTCB-index of a REAL MTCB, pointing on a message in the preparation
pool. This message is printed in the ordinary Narrative Message format ref. 3.3.5.1.
No ACCEPTANCE/RETRIEVAL DTG is printed
The classification code used at CLASSIFICATION-TEST and formatting of HEADER & TAIL is fetched
from the REAL MTCB (CLASS).
When printout is finished STATUS OF MESSAGE ref.(11) sec. 7.1.1.1., case 1 is updated to
'IN PREPARATION POOL'. I.e. right byte of WORD7 in the REAL MTCB is sat to O.
3.3.5.8. S̲p̲e̲c̲i̲a̲l̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲P̲r̲i̲n̲t̲o̲u̲t̲.̲
This printout sequence is started by an entry in the special handling gueue and a special
handling print-request. ref. sec. 3.3.3.4.
The sequence is passed just as described in sec. 3.3.5.1. - Narrative Messages with the following
modifications.
After printout is finished the TEXT-BUFFER used is cleared, i.e. overwritten with spaces.
At printing of ACCEPTANCE & RETRIEVAL-DTG the RETRIEVAL-DTG is cleared (does not exist).
3.3.6. S̲e̲q̲u̲e̲n̲c̲e̲ ̲F̲i̲n̲i̲s̲h̲
When a sequence is terminated-printing refused or finished - then some common actions has
to be done.
If the printout was completed then the queueelement read at start must be deleted. In case
of special handling printout a PURGE-flag is returned. The MTCB is enqueued to PURGE. ref.
(21).
All files used must be closed/released.
If the sequence was initialized by a print request (ref. 3.3.3.(3+4)) then an AMOS-answer
with proper completion code shall be returned.
Printout of next sequence shall be attempted
3.3.7. C̲o̲m̲m̲o̲n̲ ̲R̲o̲u̲t̲i̲o̲n̲e̲s̲
3.3.7.1. R̲e̲a̲d̲i̲n̲g̲ ̲o̲f̲ ̲F̲i̲l̲e̲s̲
This section describes the principles used when reading from the file-system (FMS-ref.(4))
into the TEXT ̲BUFFER colocated to each printer.
The files are always read in a sequential manner and in sections as close to the size of
TEXT-BUFFER as possible in order to minimize the number of fileaccesses. The scheme used
is illustrated in fig. 3.3.7.
The variables that is used to manage this is defined in the following:
FILE-BASE: Startadress of logical file
(offset in database)
FILE-OFFSET: Offset in logical file -
where to start readoperation
FILE-END: Length of logical file.
READ-OFFSET:Startaddress in TEXT-BUFFFER
of "read in"-data. This will normally be o.
READ-END: Stopadress in TEXT-BUFFER of "read in"-data.
BYTE-COUNT: Number of transferred bytes.
After a readoperation have been done the next one is prepared by:
Next FILE-OFFSET:= Old FILE ̲OFFSET + BYTE ̲COUNT
3.3.7.2. F̲o̲r̲m̲a̲t̲t̲i̲n̲g̲ ̲o̲f̲ ̲T̲E̲X̲T̲-̲B̲U̲F̲F̲E̲R̲
This section describes the principles used at those occacions where data has to be formatted
before they are printed from the TEXT-BUFFER as.
ACCEPTANCE & RETRIEVAL-DTG ref. 3.3.5.1.
TRANSACTION-LOG ref. 3.3.5.2.
MESSAGE-JOORNAL-LOG ref. 3.3.5.3.
MESSAGE-LOG ref. 3.3.5.4.
At these cases, data items are to be collected from different places and may be edited before
they can be put together in a record (one or more lines) in the TEXT-BUFFER, ready to be
printed. A 'EDIT RECORD' is used as a stage between the enterring in the buffer. When this
is filled, it is transferred to the TEXT-BUFFER.
In this way the buffer can be filled with several records in an easy controlled mannner This
is illustrated in fig. 3.3.7.2.
3.3.7.3. P̲r̲i̲n̲t̲i̲n̲g̲ ̲o̲f̲ ̲T̲E̲X̲T̲-̲B̲U̲F̲F̲E̲R̲
This section describes the principles used when printing from the TEXT-BUFFER.
The buffer has been filled either by reading data directly (ref.3.3.7.1.) or when records
was edited (ref. 3.3.7.2.) into it. The data is formatted ready to be printed except for
PAGE-FORMATTING (ref. 3.4.3.1.).
To do this it is necessary to keep track with how many lines of a page, that have been printed.
This is done by counting the "new line"-caracters. If this indicates that a PAGE-EJECT shall
take place, then the printout of TEXT-BUFFER is split up in different printout operations.
Between these, other printouts, from TAIL & HEADER-BUFFER implementing the page format, is
done. The scheme used is illustrated in fig. 3.3.7.3.
The variables that is used to manage this scheme is defined and explained in the following.:
READ-OFFSET: Startaddress of first printout operation
ref. 3.3.7.1. + 3.3.7.2.
READ-END: Stopaddress of last printout operation.
ref. 3.3.7.1. + 3.3.7.2.
PRINT-OFFSET: Startaddress of a printout operation
PRINT-END: Stopaddress of a printout operation
(determined when counting lines.)
LINE-COUNT: Number of lines already printed on a
page. Equal to the number of new line
characters.
After one printoperation have been done the next one is prepared by.
Next PRINT-OFFSET= OLD PRINT-END:
3.3.7.4. C̲h̲e̲c̲k̲ ̲o̲f̲ ̲C̲l̲a̲s̲s̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Before a printsequence is started it is tested if the classification of the operator at
the printer is high enough. This classification is fetched from the terminal control block
TCB, ref.(11), sec. 7.2.
This classification shall at least be as big as that one associated with the printsequence
( e.g. message classification). If this check fails the following is done.
1. A pseudo MTCB ref.(11), fig. 7.1.2.14-4 with reason 'Terminal has too low classification'
is created via MTCB-monitor and enquenced via QACCESS into the supervisor DT-queue.
2. Message Journal Log: 'Delivered to DT-queue' ref. (17)
3. Completion 'Classification Mismatch' return upon a possible PRINT-REQUEST ref. 3.3.3.(3
+ 4).
4. Printout sequence terminated with cause: PRINT-NOT-ALLOWED ref. 3.3.4.
3.3.8. E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Every errorcondition discovered by the PIP-process is reported by call of MON(ERROR) ref.(1).
If PIP is allowed to continue processing as in the case of LOCAL-FIX-UP and IGNORE errors,
then the following actions is taken.
If the error was a resource error (# 907, # 801, # 805) or printer timeout (# 607), then
the processing for the affected printer is delayed (1 minute). This delay is implemented
by use of the TIMER-PROCESS ref.(25).
A 'clean up' of the processing is done. I.e. the situation, as it was before the printsequence
going on was started, is restablished.
If special handling printout was going on, then a SH-timeout situation is simulated, and
SH-TIMEOUT completion is returned ref. 3.3.3.5.
After runout of delay, the processing is resumed. The erroneous printsequence will be restarted
from the beginning. In case of printer timeout, a 'clean printer'- procedure (ref. 3.3.2.)
will be executed before restart.
3.3.9. C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲
The PIP-process does the folowing checkpointing by use of the CHECKPOINT-MECHANISM. ref.(12).
1. When NARRATIVE MESSAGE printout is finished, deletion from printerqueue is checkpointed.
2. When enquening to DT is done (ref. 3.3.7.4.) then this event is checkpointed.
3. When a special handling message is enqueued to PURGE, ref. (3.3.6.) then this event is
checkpointed. (Transferring from printerqueue)
4. Upon each termination of a print sequence, the last used page number is checkpointed
5. At PIP-initializing point, and after a printer timeout ref. 3.3.8, then the last used
page number is retrieved from the earlier checkpoints.
3.4. D̲a̲t̲a̲ ̲ ̲O̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲
This section deals with FIKS data structures used by the PIP-process.
These can be devided into two categories, -external data, which is defined and described
in FIKSDATA REFFERENCE MANUAL, ref.(11), and internal data, which is only used by the PIP-process.
3.4.1. E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲ ̲s̲t̲r̲u̲c̲t̲u̲r̲e̲s̲
The following external structures shall be known by the maintainer of PIP.
1. System software structures. -AMOS events, Io-user-data structures. ref. (1) + (2).
2. FIKS QUEUES, ref. (11), sec.6.
3. MTCB, FIKS message control blocks, ref. (11) sec. 7.1.
4 TCB, Terminal Control Blocks, ref. (11) sec. 7.2.
5. FIKS Message Format ref.(11), sec. 10
6. Checkpoint AMOS-messages, ref. (11)
7. FIKS File Layout. HDB AND PDB-files,
Message Journal File, ref.(11), sec. 11.1.2., 11.2, 11.11.
Message Log File, ref. (26) + ref (11), sec. 11.1.2.5
3.4.2. I̲n̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲s̲
Internal data structures in the PIP-process is only concerned with the PIP process data.
For each logical,printer in the Node/MEDE, there is a PRINTER-RECORD. This contains data
items that is exclusively used at the processing of a single printer. One area, independent
of number of printers, is used to manage the service of different printers or as buffers
common for all printers. The content and definition of the items is described where they
are accessed in section 3 - Processing. It is noticed that with this structurre, the total
size of the PIP-process area will depend on which Node/MEDE-version it is.
3.4.3. P̲r̲i̲n̲t̲o̲u̲t̲ ̲F̲o̲r̲m̲a̲t̲s̲
In principle every printout is done line by line on an endless paper roll. When data leaves
the PIP-process for being printed it must obey the following line format.
ST BC TEXT NL
where:
ST = start byte character = #1E
BC = byte count of textstring +1
NL = new line character = #0A
The messages/remarks sent to PIP for printout will obey this format i.e. no line formatting
is necessary when printing these. When PIP generates textstrings by itself then this line
formatting must be done.
3.4.3.1 P̲a̲g̲e̲ ̲F̲o̲r̲m̲a̲t̲
PIP is responsible for formatting of every printout into pages. This shall be done using
the format defined in fig. 3.4.3.1. As there is no form control or tabulate functions available,
the formatting must be done by keeping track of the linenumber and printerhead position (from
left most).
It is seen that 47 lines of printout form a page. This will with linespace 1 1/2 correspond
to A4-format. 34 lines may contain textinformation (message text).
Each page is started with a HEADER. This contains the PAGE-ID, composed of the TERMINAL-ID
and a pagenumber. This will be independent of any system initializing, switchover, errorcondition
etc. and forever increasing.
3.4.3.2 A̲c̲c̲e̲p̲t̲a̲n̲c̲e̲ ̲&̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲-̲D̲T̲G̲ ̲F̲o̲r̲m̲a̲t̲
In case of narrative printout acceptance and retrieval time shall be printed on buttom of
the last page ref. 3.3.5.1. This shall be done using the following format.
Message Text (last page)
line no position
o 17
36 ACCEPTANCE TIME: DDHHMMZ MMM YY
37 RETRIEVAL TIME: DDHHMMZ MMM YY
Text strings Edit DTG's
The format of the DTG's is that obtained from Convert DTG. ref (13).
3.4.3.3 C̲o̲o̲r̲d̲i̲n̲a̲t̲i̲o̲n̲ ̲P̲r̲i̲n̲t̲o̲u̲t̲ ̲F̲o̲r̲m̲a̲t̲
Refer to 3.3.5.5.
line no.
04 COORDINATORS ̲IDENTY ̲text
(one or more lines)
Empty line
Message text
Empty line
ORIGINATOR REMARKS
(one or more lines)
3.4.3.4 M̲e̲s̲s̲a̲g̲e̲ ̲L̲o̲g̲ ̲F̲o̲r̲m̲a̲t̲
Refer to 3.3.5.4.
line no. position
0 18 26 41 47
04 MESSAGE LOG
06 RETRIEVAL-DTG MSG-ID..SIC..SIC..SIC..PREC...CLASS
08 DDHHMMZ.MMM.YY XXX999..XXX..XXX..XXX..X......XXXXX
09 DDHHMMZ.MMM.YY XXX999..XXX..XXX..XXX..X......XXXXX
DTG formatted via convert DTG.
Precedence code converted to ASCII-char.
Classification code translated to short Classification text (CLASS2).
3.4.3.5 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲L̲o̲g̲ ̲F̲o̲r̲m̲a̲t̲
Refer to 3.3.5.2.
line no. Position
0 4 19 28 32
04 LOG.DDHHMMZ.MMM.YY.XXXXXXXX.TID.USID
05 LOG.DDHHMMZ.MMM.YY.XXXXXXXX.TID.USID
DTG formatted
via Convert DTG.
Eventtype translated.
1: LOGON..S
2: LOGON..U
3: LOGOFF.S
4: LOGOFF.U
5: SECINT.U
Terminal ID
User ID
3.4.3.6 M̲e̲s̲s̲a̲g̲e̲ ̲J̲o̲u̲r̲n̲a̲l̲ ̲L̲o̲g̲ ̲F̲o̲r̲m̲a̲t̲
Refer for 3.3.5.3.
line no. position
0
04 JOUR.DDHHMMZ.MMM.YY.TEXT.MSG-ID.TID
05 JOUR.DDHHMMZ.MMM.YY.TEXT.MSG-ID.TID
1 2 3 4 5
1) Fixed test
2) DTG formatted via Convert DTG
3) Translation of logging type code ref. (17)
1. MERE, Message released
2. MDTQ, Message delivered to Terminal queue
3. MDDT, Message delivered to DT-queue
4. RQDP, Retrieve request for display
5. RQPR, Retrieve request for printout
6. RQDB, Retrieve request for distribution
7. DIRM, Distribution of retrieved message
8. RQRA, Retrieve request for readdressing
9. SHDT, SH-message delivered to terminal queue
10. PRNT, Message print out started.
4) Message ID
5) Terminal ID
3.5 S̲t̲o̲r̲a̲g̲e̲ ̲A̲l̲l̲o̲c̲a̲t̲i̲o̲n̲
P̲r̲o̲g̲r̲a̲m̲ ̲S̲i̲z̲e̲
The size of the PIP-program part depends sligthly on the number of printers to be served.
For an average Node/MEDE the memory claim is about
2800 words.
P̲r̲o̲c̲e̲s̲s̲ ̲S̲i̲z̲e̲
The size of the PIP-process part consist of two parts. One fixed part containing the data
common for all printers and one variable part proportional with the number of printers installed
at the specific Node/MEDE.
The memory claim is approcimately given by
1080 + No-of-printers x 485 words.
3.6 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̲
The performance of the PIP-process, i.e. its ability to printout messages, is primary limited
by the speed of the printers (low level speed output). Therefore no special considerations
have been done about the performance characteristics.
It has been noticed while testing, that the CPU-time consumption done by the PIP-process
is not very much compared with the rest of the processes in the FIKS-system.
3.7 L̲i̲m̲i̲t̲a̲t̲i̲o̲n̲s̲
Depending upon which Node/MEDE the PIP-process is generated for, it is only able to handle
a limited number of printers.
Below is a list of these:
Node/MEDE Max. no. of printer
A 13
B 12
E 26
F 27
H 17
K 25
L 18
N 9
By a easy made modification of the PIP-process it will be able to handle until 30 printers.
Exspanding the numbers further will cost a little more effort.
3.8 E̲r̲r̲o̲r̲ ̲L̲o̲c̲a̲t̲i̲o̲n̲s̲
L̲A̲B̲E̲L̲ ̲ ̲ ̲ ̲ ̲ ̲R̲a̲i̲s̲e̲n̲ ̲b̲y̲ ̲(̲c̲a̲l̲l̲ ̲o̲f̲)̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲C̲o̲m̲m̲e̲n̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
0 Inconsistence in date Error code will be #7FFF
(should never happen)
11 MON (IO,WAITOPERATIONS) At error code #0607 the print sequence going on is restarted
after 1 minuter
12 Completion error from
TIMER-process
21 MON (IO, GETROOT) MOVHEAD
22 MON (IO, GETROOT) FIXHEAD
23 MON (LCFH) Creation of Log lines to the TDX-system
24 'Cleaning up printer' In initializing phase and at local fixup after printer timeout
(#0607)
51 MON (TESTHDB)
59 MON (LOG-JOURNAL)
61 MON (IO, INITREADBYTES) From File-system - messages + remarks
62 MON (IO, READBYTES) From File-system - message Log + journal
71 MON (IO, INITAPPENDBYTES) To TDX-system
91 MON (Convert DTG)
100 MON (MTCB, INIT)
101 MON (MTCB, CREATE) When enqueing to DT (1)
102 MON (MTCB, RESERVE) General
103 MON (MTCB, RESERVE) Of messages
104 MON (MTCB, RELEASE) General
105 MON (MTCB, RELEASE) Of messages
106 MON (MTCB, WRITE) At coordination printout + enqueing to DT
107 MON (MTCB, WRITE) At list of prepared messages
L̲A̲B̲E̲L̲ ̲ ̲ ̲ ̲ ̲ ̲R̲a̲i̲s̲e̲n̲ ̲b̲y̲ ̲(̲c̲a̲l̲l̲ ̲o̲f̲)̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲C̲o̲m̲m̲e̲n̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
108 MON (MTCB, READ)
109 MON (MTCB, GETFILE) Of message
111 MON (QACCESS, READ-GROUP)
112 MON (QACC.,READ-NON-DESTR) Specat handling
115 MON (QACCESS, DELETE)
116 MON (QACCESS, WRITE) To DT-queue (1)
117 MON (QACCESS, WRITE) To PURGE-queue (1)
121 MON (REGION, RCOPYN) CLASS 1
123 MON (REGION, RCOPYN) CLASS 2
125 MON (IO, LOOKUP) MLF-file
126 MON (IO, LOOKUP) MJF-file
128 MON (IO, DISMANTLE) MLF + MJF-files
200 MON (MTCB, GETFILE) Of remarks
201 MON (MTCB, RELEASEFILE) Of messages
202 MON (MTCB, RELEASEFILE) Of remarks
221 MON (REGION, RENTER) Of CONFIG
222 MON (REGION, RLEAVE) Of CONFIG
223 MON (REGION, RPUT) Of CONFIG
N̲o̲t̲e̲:
When it is possible to locate the error to a specific printer, it is done by adding the logical
printer number muliplied by 1000 to the error label. E.g. error label 7108 (decimal value)
means:
Error after call of MON(MTCB,READ) when serving printer No. 7
(1) At errors #0801, #0805, #0907 (resource errors, local fixup) the following is done. Processing
for the affected printer is suspended in 1 minute.Then the processing is resumed from
the point where the error occured.
3.9 L̲i̲s̲t̲i̲n̲g̲ ̲R̲e̲f̲f̲e̲r̲e̲n̲c̲e̲
Source listings and linker lists may be obtained from FIXLIB. Ref. to SCCLDD.
4. Q̲U̲A̲L̲I̲T̲Y̲ ̲A̲S̲S̲U̲R̲A̲N̲C̲E̲
4.1 Q̲u̲a̲l̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲T̲e̲s̲t̲s̲
The PIP has been module tested.
Refer to TEST REPORT FOR PIP, FIX/1203/TRP/0022.
At the test 'Dual N/M Integration' focusing on special the PIP-process was done.
Refer to Test Report for I150 Dual N/M Integration, FIX/1000/TRP/0006.
4.2 O̲t̲h̲e̲r̲ ̲Q̲u̲a̲l̲i̲t̲y̲ ̲A̲s̲s̲u̲r̲a̲n̲c̲e̲ ̲P̲r̲o̲v̲i̲s̲i̲o̲n̲s̲
In many tests done in connection with the FIKS-system printouts have been done. In this way
the PIP-process has proven that it is capable to fulfill its functions.
5. P̲R̲E̲P̲A̲R̲A̲T̲I̲O̲N̲S̲ ̲F̲O̲R̲ ̲D̲E̲L̲I̲V̲E̲R̲Y̲
Do as stated in file 'INFORMATION' in the last delivery of the PIP-directory to FIXLIB.
6. N̲O̲T̲E̲S̲
6.1 M̲o̲d̲u̲l̲e̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲
The PIP is compiled as a single process (one mainmodule) by means of the SWELL compiler CSS/415
and linked by means of the AMOS Linker CSS/416, Refer to:
SWELL 80, Reference Manual,
CSS/415/RFM/0002
CR80 AMOS, SWELL Compiler, Users Manual,
CSS/415/USM/0047
CR80 AMOS, Linker, Reference Manual,
CSS/416/RFM/0003
CR80 AMOS, Linker, Users Manual,
CSS/416/USM/0048.
By using the commond files as stated in the INFORMATION-file in the last FIXLIB-delivery
of PIP it is possible to generate all or a single PIP-Node/MEDE-version.
6.2 N̲o̲d̲e̲/̲M̲E̲D̲E̲-̲v̲e̲r̲s̲i̲o̲n̲s̲
The only thing which distinguish one Node/MEDE-version from another is the number of printers
to be served.
The different PIP-processes are compiled with the same source input files, except for one
file which only contains the Node/MEDE ID declaration. In this way an updating of PIP shall
be done only at one place independent of version.
The different PIP-processes are linked with the same parameters except for those declaring
the use of IO-resources. Those are collected in a separate Node/MEDE linker parameterfile.
The coherence between these and the number of printers (NOP) is given by:
FILE ̲DESCRIPTORS (FDS) = NOP * 2.5 + 6
IO ̲CONTROL ̲BLOCKS (IOCBS) = NOP
TRANSFER ̲ELEMENTS (TLES) = NOP * 4
MESSAGES (MESSAGES) = NOP * 2
7. A̲P̲P̲E̲N̲D̲I̲C̲E̲S̲
None.
