|
DataMuseum.dkPresents historical artifacts from the history of: RegneCentralen RC850 |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about RegneCentralen RC850 Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 23168 (0x5a80)
Types: RcTekst
Names: »VIL4.WP«
└─⟦51ec6abc5⟧ Bits:30005985 Manualer - TELETEX Document Handler
└─⟦this⟧ »VIL4.WP«
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
════════════════════════════════════════════════════════════════════════
↓
┆14┆┆b3┆┆06┆- ┆0b┆ -↲
↲
┆b0┆┆a1┆7. UPDATE INFORMATION↲
↲
╞ ┆84┆This section describes the information delivered in an IND.UPDATE ↓
┆19┆┆89┆┄┄block to DS, see ref. 3. Three kind of update units exists, packet ↓
┆19┆┆89┆┄┄state, charge information and user information.↲
↲
↲
┆a1┆┆b0┆7.1 Packet State↲
↲
╞ format:↲
↲
╞ ┆a1┆ ↲
╞ ┆a1┆! unit type = 1 ! length = 1 ! packet state !↲
╞ 1 byte 1 byte 1 byte↲
↲
╞ ┆84┆The meaning of the packet states are:↲
↲
╞ (1) ┆84┆waiting for transmission.↲
╞ ┆84┆Initial state for a submit/abort packet. The packet remains in ↓
┆19┆┆8d┆┄┄this state until the first attempt is made to transmit the ↓
┆19┆┆8d┆┄┄packet.↲
↲
╞ (2) being transmitted.↲
╞ ┆84┆Normally this means that a normal document transmission is in ↓
┆19┆┆8d┆┄┄progress using a session. But the packet is also in this state ↓
┆19┆┆8d┆┄┄when a communication break down has occurred and the clean up ↓
┆19┆┆8d┆┄┄after the error is unfinished. First when it has been decided ↓
┆19┆┆8d┆┄┄what to do with the packet the state is changed.↲
↲
╞ (3) transmission temporarily suspended.↲
╞ ┆84┆The packet is either encapsulated or in the busy queue.↲
↲
╞ (4) transmission completed.↲
╞ ┆84┆This is a pseudo state, because the DH will indicate the ↓
┆19┆┆8d┆┄┄transfer to it implicit by sending a CONF.SUBMIT or a ↓
┆19┆┆8d┆┄┄CONF.REGRET.↲
↲
┆8c┆┆83┆┆c8┆↓
┆0e┆↓
╞ (5) ┆84┆transmission abandoned.↲
╞ As above. The CONF.SUBMIT (CONF.ABORT) contained a result<>ok↲
┆0f┆↓
↲
╞ (6) ready for reception.↲
╞ ┆84┆Initial state for a CREATE packet. The state will very fast be ↓
┆19┆┆8d┆┄┄changed to being received by DH.↲
↲
╞ (7) being received.↲
╞ ┆84┆A normal document receival is in progress using a session. But ↓
┆19┆┆8d┆┄┄the packet is also in this state when a communication break ↓
┆19┆┆8d┆┄┄down has occurred, and it has not been decided yet what to do ↓
┆19┆┆8d┆┄┄with the packet.↲
↲
╞ (8) reception temporary suspended.↲
╞ ┆84┆The packet is waiting for the caller to resume the transfer. A ↓
┆19┆┆8d┆┄┄timer will be running.↲
↲
╞ (9) reception complete↲
╞ ┆84┆An IND.DELIVER with result=ok was send by DH.↲
↲
╞ (10)reception abandoned.↲
╞ ┆84┆The transfer to this state will be indicated implicit by ↓
┆19┆┆8d┆┄┄sending a IND.DELIVER with result<>ok.↲
↲
↲
┆a1┆┆b0┆7.2 Charge Information↲
↲
╞ Format:↲
↲
╞ ┆a1┆ ↲
╞ ┆a1┆! unit type = 2 ! length = 9 ! charge type = 1 ! charge !↲
╞ 1 byte 1 byte 1 byte 8 bytes↲
↲
╞ Charge consists of 8 digits, defining the charge.↲
↲
╞ ┆84┆This update unit will only occur if charge has been requested in ↓
┆19┆┆89┆┄┄REQ.SUBMIT or REQ.REGRET. It is sent to DS when a CHARGE INF IND is ↓
┆19┆┆89┆┄┄received from S62CP i.e. just before the state transition "being ↓
┆19┆┆89┆┄┄transmitted -> transmission temporary suspended" or "being ↓
┆19┆┆89┆┄┄transmitted -> transmission abandoned" occurs.↲
↲
↲
┆8c┆┆83┆┆f8┆↓
┆b0┆┆a1┆7.3 User Information↲
↲
╞ Format:↲
↲
╞ ┆a1┆ ↲
╞ ┆a1┆! unit type = 3 ! info lg = ? ! user unit 1 ! - - - ! user unit n!↲
╞ 1 byte 1 byte < info lg bytes >↲
↲
╞ The format of a user unit is:↲
↲
╞ ┆a1┆ ↲
╞ ┆a1┆! info type ! unit lg ! value !↲
╞ 1 byte 1 byte < unit lg bytes >↲
↲
╞ ┆84┆It should be noted that user information can be empty, i.e. info ↓
┆19┆┆89┆┄┄lg can be zero, see below.↲
↲
╞ ┆84┆A user unit informs about the reason for a break down in a ↓
┆19┆┆89┆┄┄document transfer. All possible values of info type will not be ↓
┆19┆┆89┆┄┄described here because they originate at lower level modules, and ↓
┆19┆┆89┆┄┄will be described in the specification manual for these modules.↲
↲
╞ ┆84┆However, the last user unit (if any) will allways originate from ↓
┆19┆┆89┆┄┄DH. There will be one ore possibly two units. The last case will ↓
┆19┆┆89┆┄┄be described below (description of info type = 11).↲
↲
╞ ┆84┆An empty user information is delivered when the packet enters the ↓
┆19┆┆89┆┄┄"being transmitted" or "being received" state, and it should be ↓
┆19┆┆89┆┄┄initiated to this value by DS. If user information is non empty in ↓
┆19┆┆89┆┄┄one of the mentioned states, it means that a communication break ↓
┆19┆┆89┆┄┄down has occurred but the error clean up is not finished yet.↲
↲
╞ ┆84┆The following two values of info type indicates DH units:↲
↲
╞ ┆a1┆info type = 5, S62CP breakdown.↲
↲
╞ ┆84┆These units indicate that the initiative for the interruption ↓
┆19┆┆89┆┄┄dont come from DH, i.e. its either a session break down, or an ↓
┆19┆┆89┆┄┄interruption requested from the remote terminal. In these cases it ↓
┆8c┆┆83┆┆d4┆↓
┆19┆┆89┆┄┄will always be a S62CP primitive which has caused the breakdown, ↓
┆19┆┆89┆┄┄and the user must refer to ref. 4.↲
↲
╞ The general format for these units are:↲
↲
╞ ┆a1┆ ↲
╞ ┆a1┆! info type = 5 ! unit lg = 1 or 2 ! error kind ! error info !↲
╞ 1 byte 1 byte 1 byte 0 or 1 byte↲
↲
╞ ┆84┆error kind identifies the S62CP primitive received. The following ↓
┆19┆┆89┆┄┄values can occur:↲
↲
╞ (1) error kind = 1, unit lg = 2↲
↲
╞ ┆84┆A SESS START CONF NEG has been received. (The packet was ↓
┆19┆┆8d┆┄┄initiator for this session, see section 6.3).↲
╞ ┆84┆error info contains the rej reason parameter. Note that no ↓
┆19┆┆8d┆┄┄user info is generated when rej reason = busy. In this case a ↓
┆19┆┆8d┆┄┄short encapsulation will be made without informing the DS.↲
↲
╞ (2) error kind = 2, unit lg = 2↲
↲
╞ ┆84┆A SESS ABORT IND was received on a session to which this ↓
┆19┆┆8d┆┄┄packet was connected.↲
╞ ┆84┆error info contains the ab reason parameter. The value lpe ↓
┆19┆┆8d┆┄┄will not occur, because this value indicates that the user has ↓
┆19┆┆8d┆┄┄made a protocol error.↲
↲
╞ (3) error kind = 3, unit lg = 2↲
↲
╞ ┆84┆An EXCEPTION IND has been received. "error info" contains the ↓
┆19┆┆8d┆┄┄except reason parameter. The DH will have sent a RESYNCHRONIZE ↓
┆19┆┆8d┆┄┄REQ on behalf on the packet.↲
↲
╞ (4) error kind = 4, unit lg = 2↲
↲
╞ ┆84┆A DOCUMENT DISCARD IND has been received. "error info" ↓
┆19┆┆8d┆┄┄contains the discard_reason parameter.↲
↲
┆8c┆┆83┆┆d4┆↓
╞ (5) error kind = 5, unit lg = 2↲
↲
╞ ┆84┆A DOCUMENT RESYNCHRONIZE IND has been received. "error info" ↓
┆19┆┆8d┆┄┄contains the resynch reason parameter.↲
↲
╞ (6) error kind = 6, unit lg = 1↲
╞ ↲
╞ ┆84┆A CAP CONF NEG has been received, i.e. the receiving terminal ↓
┆19┆┆8d┆┄┄has not the required capabilities.↲
↲
╞ (7) error kind = 1, unit lg = 2↲
↲
╞ ┆84┆A DOCUMENT CONTINUE IND has been received, which defines a ↓
┆19┆┆8d┆┄┄forward jump in checkpoint numbers. "error info" contains the ↓
┆19┆┆8d┆┄┄size of this jump (255 if >= 255).↲
╞ ┆84┆The other side has made a protocol error, and a DOCUMENT ↓
┆19┆┆8d┆┄┄CONTINUE RESP NEG has been sent.↲
↲
╞ ┆a1┆info type = 11, Document stream troubles↲
↲
╞ ┆84┆These units indicate that the cause for the interruption is a ↓
┆19┆┆89┆┄┄break down of the document stream.↲
↲
╞ The general format for these units are:↲
↲
╞ ┆a1┆ ↲
╞ ┆a1┆! info type = 11 ! unit lg = 1 or 2 ! error kind ! error info !↲
╞ 1 byte 1 byte 1 byte 0 or 1 byte↲
↲
╞ error kind identifies the kind of trouble.↲
↲
╞ (1) error kind = 1, unit lg = 2↲
↲
╞ ┆84┆A REPLY NOT OK has been received. error info contains the code ↓
┆19┆┆8d┆┄┄field.↲
↲
╞ (2) error kind = 2, unit lg = 1↲
╞ ↲
╞ ┆84┆A premature TTXSI stream close has been received on the ↓
┆19┆┆8d┆┄┄document stream.↲
↲
┆8c┆┆83┆┆ec┆↓
╞ (3) error kind = 3, unit lg = 2↲
↲
╞ ┆84┆Document stream protocol error↲
┆84┆error info identifies the kind of error in the following way:↲
↲
╞ 1: ┆84┆Other than REPLY OK as answer on TRANSFER from DH. (REPLY ↓
┆19┆┆90┆┄┄NOT ok is, of course, always possible, except after STREAM ↓
┆19┆┆90┆┄┄END).↲
↲
╞ 2: ┆84┆no data between CHECKPOINT blocks, or no data between a ↓
┆19┆┆90┆┄┄CHECKPOINT and a STREAM END, in a read operation.↲
↲
╞ 3: ┆84┆premature STREAM END received in a write operation.↲
↲
╞ 4: CHECKPOINT as answer on a STREAM END in a write operation.↲
↲
╞ 5: STREAM block received in a write operation.↲
↲
╞ ┆84┆Note that any blocks received after a STREAM END will, ↓
┆19┆┆90┆┄┄though erroneous be ignored. Normal document level ↓
┆19┆┆90┆┄┄termination will already have been initiated by DH.↲
↲
╞ (4) error kind = 4, unit lg = 2↲
↲
╞ ┆84┆This indicates a format error in a received document stream ↓
┆19┆┆8d┆┄┄block. info contains the header byte.↲
↲
╞ ┆84┆The action taken by DH when info type = 11 will be ↲
↲
╞ - for source packets:↲
╞ ┆84┆A DOCUMENT RESYNCHRONIZE REQ is sent if the sessions are inside ↓
┆19┆┆8b┆┄┄the document level. If the other side responds with SESSION ↓
┆19┆┆8b┆┄┄ABORT IND, user information will contain two user units, the one ↓
┆19┆┆8b┆┄┄with info type = 11, and the other with info type = 5 (and error ↓
┆19┆┆8b┆┄┄kind = 2). The one with info type=11 occurs last.↲
↲
┆8c┆┆83┆┆b0┆↓
┆0e┆↓
╞ - for sink packets:↲
╞ ┆84┆A EXCEPTION REQ is sent. The other side responds with a DOCUMENT ↓
┆19┆┆8b┆┄┄RESYNCHRONIZE IND, a DOCUMENT DISCARD IND, or a SESSION ABORT ↓
┆19┆┆8b┆┄┄IND. Also in this case there will be two user units, the one ↓
┆19┆┆8b┆┄┄with info type = 11, and the other with info type = 5 (and error ↓
┆19┆┆8b┆┄┄kind = 2, 4 or 5). The one with info type=11 occurs last.↲
↲
╞ ┆84┆However the above mentioned only holds for TTX packets. In TLX ↓
┆19┆┆8b┆┄┄mode, a SESS ABORT REQ is sent from this side.↲
┆0f┆↓
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆8. CONFIGURATION PARAMETERS↲
↲
╞ ┆84┆In this section various configuration parameters are explained. ↓
┆19┆┆89┆┄┄They are of two kinds↲
↲
╞ - Compilation parameters.↲
╞ ┆84┆They are declared in an environment, and a change requires ↓
┆19┆┆8b┆┄┄recompilation of DH.↲
↲
╞ - ┆84┆Process parameters.↲
╞ ┆84┆They are transferred to the DH when its created, and should be ↓
┆19┆┆8b┆┄┄known to the father process.↲
↲
╞ ┆84┆A third kind is possible, namely parameters updated via LCP ↓
┆19┆┆89┆┄┄control messages. Such parameters dont exists in the present ↓
┆19┆┆89┆┄┄version.↲
↲
↲
┆b0┆┆a1┆8.1 The Associates List↲
↲
╞ ┆84┆When a session exists, and this side is source, the other side can ↓
┆19┆┆89┆┄┄request a change in the source/sink relationship, called a change ↓
┆19┆┆89┆┄┄in control. This is only interesting when this side is caller, ↓
┆19┆┆89┆┄┄otherwise the control should be changed in all cases.↲
↲
╞ ┆84┆Such a request should not automatically be granted, however, ↓
┆19┆┆89┆┄┄because the caller is charged for the session. Therefore is the ↓
┆19┆┆89┆┄┄┆a1┆associates list┆e1┆ introduced.↲
↲
╞ It is declared like this↲
↲
╞ associates_list: array (1..?) of ti_mask;↲
↲
╞ ┆84┆ti_mask is a type which contains a terminal identifier. Part 4 is ↓
┆19┆┆89┆┄┄optional, though (and is meaningless).↲
↲
╞ ┆84┆When a PLEASE CHANGE CONTROL IND is received, a sequential search ↓
┆19┆┆89┆┄┄is made in associates list for the addressee TI parameter. When ↓
┆19┆┆89┆┄┄"A" denotes an entry in associates list, a match occurs when:↲
↲
┆8c┆┆83┆┆e0┆↓
╞ - ┆84┆part 1, part 2 and part 3 is alike in A and addressee TI.↲
╞ - ┆84┆part 1 and part 2 is alike in A and addressee TI, and part 3 is ↓
┆19┆┆8b┆┄┄missing in A.↲
↲
╞ ┆84┆Associates list is scanned until a match occurs in which case the ↓
┆19┆┆89┆┄┄search is successfull, or until the whole table is scanned. If the ↓
┆19┆┆89┆┄┄search is successfull, the request can be granted, otherwise its ↓
┆19┆┆89┆┄┄ignored.↲
↲
╞ Associates list is a process parameter.↲
↲
↲
┆b0┆┆a1┆8.2 Telex Conversion Address↲
↲
╞ ┆84┆This parameter is used when the CU communicates with the ↓
┆19┆┆89┆┄┄Teletex/Telex conversion unit. It is declared like this:↲
↲
╞ tlx_conv_adr: ti_mask↲
↲
╞ ┆84┆This address is used for outgoing sessions when service id for the ↓
┆19┆┆89┆┄┄initiating packet is TLX. For incomming calls, the following check ↓
┆19┆┆89┆┄┄is made: If part 1 and part 2 in "calling TI" equals part 1 and ↓
┆19┆┆89┆┄┄part 2 in tlx_conv_adr, the packet received in the session will ↓
┆19┆┆89┆┄┄get service id = TLX.↲
↲
↲
┆b0┆┆a1┆8.3 Transmission Error Recovery↲
↲
╞ ┆84┆As explained in section 6.4.4 the following two values should be ↓
┆19┆┆89┆┄┄decided when a document transmission break down occurs:↲
↲
╞ retry_count:↲
╞ ┆84┆How many times the same error should be allowed to occur in ↓
┆19┆┆89┆┄┄sequence before the DH gives up. Zero means immidiate giveup.↲
↲
╞ retry_timer:↲
╞ ┆84┆The duration of the encapsulation made when this error occurs, ↓
┆19┆┆89┆┄┄measured in minutes. Has as a matter of fact only meaning when ↓
┆19┆┆89┆┄┄retry_count is non zero. If it is zero, it indicates an immediate ↓
┆19┆┆89┆┄┄retry.↲
↲
┆8c┆┆83┆┆ec┆↓
╞ ┆84┆It is the "user inf" field in the packet description which ↓
┆19┆┆89┆┄┄contains information about which kind of error it is. Please refer ↓
┆19┆┆89┆┄┄to section 7.3. As explained there, the last "user unit" in this ↓
┆19┆┆89┆┄┄field originates from DH, and it is this unit which controls the ↓
┆19┆┆89┆┄┄error recovery.↲
↲
╞ A DH user unit has the structure:↲
↲
╞ dh_user_unit = record↲
╞ ╞ info_type: byte;↲
╞ ╞ unit_lg: byte;↲
╞ ╞ error_kind: byte;↲
╞ ╞ error_info: byte↲
╞ ╞ end;↲
↲
╞ ┆84┆unit_lg is equal to 1 or 2. In the last case error_info will↓
┆19┆┆89┆┄┄contain additional information.↲
↲
╞ ┆84┆It should be noted that user inf can contain some pseudo user unit ↓
┆19┆┆89┆┄┄formats, which is not described in section 7.3, and therefore not ↓
┆19┆┆89┆┄┄are delivered to DH:↲
↲
╞ ┆84┆info_type = 5, unit_lg = 2, error_kind = 1, error_info = busy↲
╞ ┆84┆A SESSION START CONF NEG received with rej reason = busy, or a ↓
┆19┆┆89┆┄┄SESSION START REQ has been answered by S62CP with result = busy. ↓
┆19┆┆89┆┄┄This is not regarded as an error because the packet probably will ↓
┆19┆┆89┆┄┄soon enter the busy queue.↲
↲
╞ info_type = 5, unit_lg = 1, error_kind = 101↲
╞ ┆84┆A priority break has occurred for a SUBMIT packet.↲
↲
╞ ┆84┆The table which controls the transmission error recovery, submit ↓
┆19┆┆89┆┄┄error table, is then declared like this:↲
┆8c┆┆83┆┆8c┆↓
┆0e┆↓
↲
╞ submit_error_table: array (1..?) of ↲
record↲
╞ error_unit: dh_user_unit;↲
╞ retry_count: byte;↲
╞ retry_timer: byte;↲
╞ end;↲
┆0f┆↓
↲
╞ ┆84┆When "act_user_unit" denotes the first user unit in user inf, and ↓
┆19┆┆89┆┄┄"search entry" an entry in submit_error_table, a match occurs if ↓
┆19┆┆89┆┄┄one of the following conditions holds:↲
↲
╞ (1) act_user_unit = search_entry. error_unit↲
↲
╞ (2) act_user_unit. info_type = search_entry. error_unit. info_type↲
╞ and↲
╱04002d440c00060000000003015131000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╞ act_user_unit. error_kind = search_entry. error_unit. error_kind↓
╱04002d440c00060000000003014b31000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003015131000000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╞ and↲
╞ search_entry. error_unit. error_info = 255↲
↲
╞ ┆84┆This kind of entry contains default parameters for all this ↓
┆19┆┆8d┆┄┄values of info_type and error kind.↲
↲
╞ (3) act_user_unit. info_type = search_entry. error_unit. info_type↲
and↲
╞ ┆84┆search_entry. error_unit. error_kind=255↲
↲
╞ ┆84┆This kind of entry contains default parameters for this value ↓
┆19┆┆8d┆┄┄of info_type.↲
↲
╞ (4) search_entry. error_unit. info_type = 255↲
╞ ┆84┆This is a default entry which should be placed last in the ↓
┆19┆┆8d┆┄┄table.↲
↲
╞ ┆84┆When an error has occurred submit_error_table is searched from the ↓
┆19┆┆89┆┄┄beginning until a match occurs. The found entry contains the ↓
┆19┆┆89┆┄┄values of retry_count and retry_timer which should be used.↲
↲
┆8c┆┆83┆┆c8┆↓
┆0e┆↓
╞ ┆84┆example: The following is a possible part of submit_error_table:↲
↲
╞ ! !↲
╞ ! !↲
╞ ┆a1┆! !↲
╞ !info_type : 5 !↲
╞ !unit_lg : 2 !↲
╞ !error_kind : 2 !↲
╞ !error_info : rem_term_err !↲
╞ !retry_count : 1 !↲
╞ ┆a1┆!retry_timer : 10 !↲
╞ !info_type : 5 !↲
╞ !unit_lg : 2 !↲
╞ !error_kind : 2 !↲
╞ !error_info : prot_timeout !↲
╞ !retry_count : 3 !↲
╞ ┆a1┆!retry_timer : 3 !↲
╞ !info_type : 5 !↲
╞ !unit_lg : 2 !↲
╞ !error_kind : 2 !↲
╞ !error_info : proc_err !↲
╞ !retry_count : 0 !↲
╞ ┆a1┆!retry_timer : 0 !↲
╞ !info_type : 5 !↲
╞ !unit_lg : 2 !↲
╞ !error_kind : 2 !↲
╞ !error_info : 255 !↲
╞ !retry_count : 10 !↲
╞ ┆a1┆!retry_timer : 1 !↲
╞ ! !↲
╞ ! !↲
╞ ! !↲
┆0f┆↓
┆f0┆┆f0┆↲
╞ This part of the table has the following meaning:↲
↲
╞ ┆84┆When a SESSION ABORT IND has been received, retry_count and ↓
┆19┆┆89┆┄┄retry_timer will get the following values, depending on the ↓
┆19┆┆89┆┄┄ab_reason parameter (contained in error info):↲
↲
┆8c┆┆83┆┆d4┆↓
╞ rem_term_err:↲
╞ retry_count = 1, retry_timer = 10.↲
↲
╞ prot_timeout:↲
╞ retry_count = 3, retry timer = 3.↲
↲
╞ proc_err:↲
╞ retry_count = 0 (giveup)↲
↲
╞ ┆84┆other values (unspec_reason, nc_cleared, pers_err):↲
╞ retry_count = 10, retry_timer = 1.↲
↲
╞ ┆84┆The content of submit error table will not be given here because ↓
┆19┆┆89┆┄┄it is the subject of further study. (For certain kind of errors, ↓
┆19┆┆89┆┄┄some practical experience). The following considerations can be ↓
┆19┆┆89┆┄┄made, however:↲
↲
╞ (1) info type = 5, error kind = 1.↲
╞ SESS START CONF NEG received↲
↲
╞ ┆84┆rej_reason = net_not_acc, rec_unkw, ill_fac, redirected, ↓
┆19┆┆8d┆┄┄na_mism, ta_mism or mnem_mism should be a giveup.↲
↲
╞ ┆84┆rej_reason = address enc. Here is the retry_timer value dummy, ↓
┆19┆┆8d┆┄┄because the encapsulation duration is given in the wait_time ↓
┆19┆┆8d┆┄┄parameter.↲
↲
╞ ┆84┆rej_reason = busy. Here, too, is the retry_timer value dummy. ↓
┆19┆┆8d┆┄┄The busy_retry_timer is used instead (see below).↲
↲
╞ ┆84┆The fixing of retry_count and retry_timer for other values of ↓
┆19┆┆8d┆┄┄rej_reason is for further study.↲
↲
╞ (2) info type = 5 error_kind = 2↲
╞ ┆84┆SESS ABORT IND received.↲
↲
╞ ┆84┆ab_reason = proc_err should (probably) be a giveup.↲
╞ ┆84┆Fixing of the error recovery parameters for other values of ↓
┆19┆┆8d┆┄┄ab_reason is for further study.↲
↲
┆8c┆┆83┆┆e0┆↓
╞ (3) info_type = 5, error_kind = 3↲
╞ EXCEPTION IND received.↲
↲
╞ except reason = proc_err should be a giveup.↲
↲
╞ other values of except reason: for further study.↲
↲
╞ (4) info_type = 5, error kind = 6.↲
╞ ┆84┆A CAP CONF NEG has been received. giveup.↲
↲
↲
╞ (5) unit_type = 5, error_kind = 101↲
╞ ┆84┆A priority break. retry_count should be something great, and ↓
┆19┆┆8d┆┄┄retry_time should be zero.↲
↲
╞ (6) info_type = 11.↲
╞ ┆84┆Probably a giveup. Something is wrong with the IMC network or ↓
┆19┆┆8d┆┄┄the DS.↲
↲
╞ ┆84┆The submit_error table is a compilation parameter.↲
↲
╞ ┆84┆Two other configuration parameters are used to control trans┄↓
┆19┆┆89┆┄┄mission error recovery:↲
↲
╞ ┆a1┆┆84┆busy retry timer┆e1┆: gives the encapsulation duration if busy is ↓
┆19┆┆89┆┄┄indicated from S62CP i.e. unit_type = 5, error kind = 1, ↓
┆19┆┆89┆┄┄error_info = busy. The duration is given in milliseconds.↲
↲
╞ ┆a1┆┆84┆max retry timer┆e1┆: If the total amount of minutes this packet has ↓
┆19┆┆89┆┄┄been encapsulated expires the value, no further encapsulation will ↓
┆19┆┆89┆┄┄be made, but a giveup will be performed.↲
↲
╞ ┆84┆Both these parameters are compilation parameters.↲
↲
↲
┆a1┆┆b0┆8.4 Receival Error Recovery↲
↲
╞ ┆84┆As explained in section 6.5.4, it should be decided whether to ↓
┆19┆┆89┆┄┄give up or not when a document receival breaks down.↲
↲
┆8c┆┆83┆┆e0┆↓
╞ ┆84┆Here too, it is the user inf field which controls the error ↓
┆19┆┆89┆┄┄recovery. See section 8.3 for the format of a "dh_user_unit". The ↓
┆19┆┆89┆┄┄possible content of user_unit is explained in section 7.3.↲
↲
╞ ┆84┆The table which controls the receival error recovery, ↓
┆19┆┆89┆┄┄receival_error_table, is declared like this:↲
↲
╞ receival_error_table: array (1..?) of ↲
record↲
╞ error_unit: dh_user_unit;↲
╞ giveup: boolean;↲
╞ end;↲
↲
╞ ┆84┆The search in receival error table is done in the same way as for ↓
┆19┆┆89┆┄┄submit_error_table (see section 8.3), and it delivers the boolean ↓
┆19┆┆89┆┄┄giveup.↲
↲
╞ ┆84┆The content of receival error table is not finally fixed at ↓
┆19┆┆89┆┄┄present, but the following can be stated (see section 7.3):↲
↲
╞ (1) info_type = 5, error_kind = 2↲
╞ ┆84┆SESS ABORT IND received, giveup should be false, except maybe ↓
┆19┆┆8d┆┄┄for ab_reason = proc_err.↲
↲
╞ (2) info_type = 5, error_kind = 4↲
╞ ┆84┆DOCUMENT DISCARD IND received. Should not occur in the table, ↓
┆19┆┆8d┆┄┄because packet termination will be performed (after an ERASE)↲
↲
╞ (3) info=type = 5, error_kind = 5↲
╞ ┆84┆DOCUMENT RESYNCHRONIZE IND has been received, giveup = false ↓
┆19┆┆8d┆┄┄except maybe for resynch_reason = proc_err.↲
↲
╞ (4) info_type = 5, error_kind = 7↲
╞ ┆84┆DOCUMENT CONTINUE IND has been received with illegal ↓
┆19┆┆8d┆┄┄checkpoint number. giveup = true.↲
↲
┆8c┆┆83┆┆b0┆↓
┆0e┆↓
╞ (5) info_type = 11↲
╞ ┆84┆Document stream troubles. giveup = true except in the ↓
┆19┆┆8d┆┄┄following case:↲
╞ ┆84┆error_kind = 1, error_info = 3 (no resources). The reason = 1 ↓
┆19┆┆8d┆┄┄(temporarily unable ---) has been given as parameter to a DOC ↓
┆19┆┆8d┆┄┄RESYNCHRONIZE REQ. giveup should be false.↲
┆0f┆↓
↲
╞ ┆84┆receival error table is a compilation parameter.↲
↲
╞ ┆84┆The amount of minutes to wait for a continuation (when giveup = ↓
┆19┆┆89┆┄┄false) is contained in another compilation parameter, ┆a1┆packet_wait ↓
┆19┆┆89┆┄┆84┆time.↲
↲
┆8c┆┆81┆┆9c┆↓
┆0e┆↓
↲
┆b0┆┆a1┆8.5 Other Configuration Parameters↲
↲
╞ (a) no_of_tu.↲
╞ ┆84┆Number of TU descriptions in DH. Should be equal to the ↓
┆19┆┆8d┆┄┄corresponding parameters for TTXSI. This is a process ↓
┆19┆┆8d┆┄┄parameter.↲
↲
╞ (b) cu_ta.↲
╞ ┆84┆A TI mask, which decides whether a session is used for ↓
┆19┆┆8d┆┄┄internal loop or not.↲
↲
╞ (c) no_of_packets.↲
╞ ┆84┆Number of packet descriptions in DH. Has no correspondence ↓
┆19┆┆8d┆┄┄with other configuration parameters in the CU but should be as ↓
┆19┆┆8d┆┄┄great as the core allows. A process parameter.↲
↲
╞ (d) class 0 pages↲
╞ ┆84┆Max number of pages in a class 0 submit packet. A process ↓
┆19┆┆8d┆┄┄parameter.↲
↲
╞ (e) no_of_net_conns↲
╞ ┆84┆Number of possible connections (sessions) to the network. =1 ↓
┆19┆┆8d┆┄┄for a x21 network. A process parameter.↲
↲
╞ (f) max_sess_nu↲
╞ ┆84┆Max number of sessions possible in DH. A process parameter.↲
╞ ┆84┆Should be equal to the max number of sessions for S62CP.↲
┆0f┆↓
════════════════════════════════════════════════════════════════════════
↓
↲
┆a1┆A╞ References↲
↲
╞ (1)╞ ┆84┆Control Procedures for Teletex and Group 4 Facsimile ↓
┆19┆┆93┆┄┄services↲
╞ ╞ CCITT Recommendation S.62↲
╞ ╞ (Revised version 4; August 1983)↲
↲
╞ (2) ╞ RCSL No. 43-GL12082↲
╞ ╞ ┆84┆Teletex Control Unit.↲
╞ ╞ Functional Specification↲
↲
╞ (3)╞ RCSL No. 999 09868↲
╞ ╞ Teletex Control Unit↲
╞ ╞ Interface description↲
╞ ╞ Reference Manual↲
↲
╞ (4)╞ RCSL No. 43-GL12247↲
╞ ╞ Teletex Control Unit.↲
╞ ╞ ┆84┆S62CP - S.62 Communication program↲
╞ ╞ Reference Manual↲
↲
╞ (5)╞ RCSL No. 43-GL12252↲
╞ ╞ Teletex control unit↲
╞ ╞ NCP Data structures↲
╞ ╞ Reference Manual↲
════════════════════════════════════════════════════════════════════════
↓
↲
┆a1┆B.╞ TTXDH Program head.↲
↲
╞ The program head for DH is declared like this:↲
↲
╞ associates_list_type(max_associates: octet) =↲
╞ array(1..max_associates) of ti_mask;↲
↲
╞ program ttxdh(↲
╞ inspect↲
╞ dh_main:╞ ╞ tab_pointer;↲
╞ inspect↲
╞ ttxsi_main,↲
╞ s62cp_main:╞ mbx_pointer;↲
╞ inspect↲
╞ hard_wait:╞ tab_pointer;↲
╞ inspect↲
╞ associates_list: ╞ associates_list_type;↲
╞ tlx_conv_adr,↲
╞ cu_ta:╞ ╞ ti_mask;↲
╞ no_of_tu,↲
╞ no_of_packets,↲
╞ max_sess_nu↲
╞ class_0_pages,↲
╞ no_of_net_conns:╞ integer)↲
↲
↲
╞ The meaning of the parameters is↲
↲
╞ dh_main : Entry semaphore for DH.↲
╞ ttxsi_main : Points on the entry mailbox for ttxsi.↲
╞ s62cp_main : Points on the entry mailbox for s62cp.↲
╞ hard_wait╞ : ┆84┆Used by DH as return mailbox for messages to ↓
┆19┆┆9b┆┄┄s62cp, which will be answered right away, and ↓
┆19┆┆9b┆┄┄where the answer is only a free buffer resource. ↓
┆19┆┆9b┆┄┄Hard wait is made global to make it possible to ↓
┆19┆┆9b┆┄┄snoop it.↲
╞ ┆84┆associates_list, tlx_conv_adr, cu_ta, no_of_tu, no_of_packets, ↓
┆19┆┆89┆┄┄max_sess_no, class_0_pages, no_of_net_conns is configuration ↓
┆19┆┆89┆┄┄parameters, see chapter 8.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
┆1a┆┆1a┆rue.↲
↲
┆8c┆┆83┆┆b0┆↓
┆0e┆↓
╞ (5) info_type = 11↲
╞ ┆84┆Document stream troubles. giveup = true except in the ↓
┆19┆┆8d┆┄