|
DataMuseum.dkPresents historical artifacts from the history of: CP/M |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about CP/M Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 275968 (0x43600)
Types: RcTekst
Names: »43G11738.WP«
└─⟦975e936c7⟧ Bits:30005865 Manualer - tekstfiler 43-GL afdelingen
└─⟦this⟧ »43G11738.WP«
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
════════════════════════════════════════════════════════════════════════
↓
┆14┆┆b3┆┆06┆i↲
┆14┆┆b3┆↲
┆a1┆┆b0┆TABLE OF CONTENTS┆05┆PAGE↲
↲
┆b0┆1. INTRODUCTION ┆f0┆...................................................... 1↲
1.1 Structure of this Manual ..................................... 1↲
1.2 Terminology and Notation ..................................... 2↲
↲
┆b0┆2. MODULE OVERVIEW ┆f0┆................................................... 4↲
↲
┆b0┆3. PROCESS COMMUNICATION ┆f0┆............................................. 16╞ ↲
3.1 External Communication ....................................... 16↲
╞ 3.1.1 DTE User Interface .................................... 17↲
╞ 3.1.2 Access to the HDLCLCP ................................. 18↲
╞ 3.1.3 Access to the NCP Module .............................. 21↲
3.2 Internal Communication ....................................... 25↲
╞ 3.2.1 Process dte ........................................... 26↲
╞ 3.2.1.1 Messages received ............................ 26↲
╞ 3.2.1.2 Messages sent ................................ 32↲
╞ 3.2.2 Process dte access .................................... 34↲
╞ 3.2.2.1 Messages received ............................ 34↲
╞ 3.2.3 Process dte hrec ...................................... 42↲
╞ 3.2.3.1 Messages received ............................ 42↲
╞ 3.2.4 Process dte lcnzero ................................... 43↲
╞ 3.2.4.1 Messages received ............................ 44↲
╞ 3.2.4.2 Messages sent ................................ 47↲
╞ 3.2.5 Process dte chan ...................................... 48↲
╞ 3.2.5.1 Messages received ............................ 49↲
╞ 3.2.5.2 Messages sent ................................ 52↲
╞ 3.2.6 Process dte pool ...................................... 54↲
↲
┆b0┆4. PROCESS DESCRIPTIONS ┆f0┆.............................................. 55↲
4.1 General Information .......................................... 56↲
╞ 4.1.1 Common Data Structures ................................ 56↲
╞ 4.1.1.1 User Table ................................... 56↲
╞ 4.1.1.2 Semaphore Area for dte chan xxx .............. 57↲
╞ 4.1.1.3 x25 param type ............................... 58↲
╞ 4.1.1.4 Zones ........................................ 60↲
╞ 4.1.2 Common or General Procedures .......................... 60↲
╞ 4.1.2.1 X.25 Procedures .............................. 60↲
════════════════════════════════════════════════════════════════════════
↓
┆14┆┆b3┆┆06┆ii↲
↲
╞ 4.1.2.2 Modem Signals Handling ....................... 63↲
╞ 4.1.2.3 User Table Operations ........................ 64↲
╞ 4.1.2.4 Error Text Procedures ........................ 65↲
╞ 4.1.2.5 Tracing Procedures ........................... 66↲
╞ 4.1.2.6 Internal Test Procedures ..................... 67↲
╞ 4.1.3 Buffer Pools .......................................... 68↲
╞ 4.1.4 Timers in the DTE Module .............................. 71↲
╞ 4.1.5 Relation between Streams and Logical Channels ......... 72↲
╞ 4.1.6 Addresses used by the DTE ............................. 73↲
╞ 4.1.6.1 User Identification .......................... 76↲
╞ 4.1.6.2 DTE Address .................................. 77↲
╞ 4.1.6.3 Address Procedures ........................... 79↲
╞ 4.1.7 Naming of Running Process Incarnations ................ 81↲
4.2 Description of dte ........................................... 83↲
╞ 4.2.1 Process Parameters .................................... 83↲
╞ 4.2.2 States ................................................ 86↲
╞ 4.2.3 Semaphore and Reference Variables ..................... 88↲
╞ 4.2.4 Data Structures ....................................... 91↲
╞ 4.2.5 Semaphores and Message Flow ........................... 94↲
╞ 4.2.6 Overview of Process Operation ......................... 95↲
╞ 4.2.7 Creation and Removal of dte chan Process Incarnation .. 106↲
╞ 4.2.8 HDLC Event Handling ................................... 110↲
4.3 Description of dte access .................................... 113↲
╞ 4.3.1 Process Parameters .................................... 113↲
╞ 4.3.2 States ................................................ 114↲
╞ 4.3.3 Semaphore and Reference Variables ..................... 117↲
╞ 4.3.4 Data Structures ....................................... 119↲
╞ 4.3.5 Semaphores and Message Flow ........................... 120↲
╞ 4.3.6 Overview of Process Operation ......................... 121↲
4.4 Description of dte hrec ...................................... 124↲
╞ 4.4.1 Process Parameters .................................... 124↲
╞ 4.4.2 States ................................................ 125↲
╞ 4.4.3 Semaphore and Reference Variables ..................... 125↲
╞ 4.4.4 Data Structures ....................................... 126↲
╞ 4.4.5 Semaphores and Message Flow ........................... 127↲
╞ 4.4.6 Overview of Process Operation ......................... 128↲
════════════════════════════════════════════════════════════════════════
↓
┆14┆┆b3┆┆06┆iii↲
↲
4.5 Description of dte lcnzero ................................... 130↲
╞ 4.5.1 Process Parameters .................................... 130↲
╞ 4.5.2 States ................................................ 132↲
╞ 4.5.3 Semaphores and Reference Variables .................... 133↲
╞ 4.5.4 Data Structures ....................................... 133↲
╞ 4.5.5 Semaphores and Message Flow ........................... 134↲
╞ 4.5.6 Overview of Process Operation ......................... 135↲
4.6 Description of dte chan ...................................... 138↲
╞ 4.6.1 Process Parameters .................................... 138↲
╞ 4.6.2 States ................................................ 140↲
╞ 4.6.3 Semaphores and Reference Variables .................... 141↲
╞ 4.6.4 Data Structures ....................................... 142↲
╞ 4.6.5 Semaphores and Message Flow ........................... 145↲
╞ 4.6.6 Overview of Process Operation ......................... 146↲
╞ 4.6.7 Description of dte chan local input semaphores ........ 154↲
╞ 4.6.8 The Strategy for Acknowledgement of Data Packets ...... 155↲
╞ 4.6.9 Maintance of Output Data Sequence ..................... 158↲
↲
┆b0┆5 ERROR MESSAGES ┆f0┆.................................................... 160↲
5.1 Error Messages from error text ............................... 160↲
5.2 Error Messages from error report and trace ................... 171↲
↲
┆b0┆6. TRACE AND DEBUG TOOLS ┆f0┆............................................. 173↲
6.1 Trace System ................................................. 173↲
6.1.1 Process Overview and Operation ........................ 173↲
6.1.2 External Communication ................................ 177↲
6.1.3 Operator Commands ..................................... 180↲
6.1.4 Traceoutput Description ............................... 181↲
6.2 Internal Test System ......................................... 183↲
6.2.1 Process Overview and Operation ........................ 183↲
6.2.2 External Communication ................................ 188↲
6.2.3 Operator Commands ..................................... 191↲
6.2.4 Testoutput Description ................................ 193↲
6.2.4.1 Testoutput frm Process dte ................... 194↲
6.2.4.2 Testoutput from Process dte lcnzero .......... 196↲
════════════════════════════════════════════════════════════════════════
↓
┆14┆┆b3┆┆06┆iv↲
↲
6.2.4.3 Testoutput from Process dte chan ............. 198↲
6.2.4.4 Communication Line Status Information ........ 200↲
6.2.4.5 dte access Test Message Print ................ 203↲
6.3 Message Snoop ................................................ 205↲
↲
┆b0┆7. CONFIGURATION GUIDE ┆f0┆............................................... 207↲
7.1 Configuration Parameters ..................................... 207↲
7.1.1 Compilation Parameters ................................ 207↲
7.1.2 Creation Parameters ................................... 208↲
7.1.3 Special Default Values ................................ 210↲
7.1.4 Configuration of Trace, Test and Snoop Systems ........ 211↲
7.2 Storage Requirements ......................................... 212↲
7.2.1 Code .................................................. 213↲
7.2.2 Stack ................................................. 214↲
7.2.3 Buffer Pools .......................................... 215↲
7.2.4 Static and Dynamic Requirements ....................... 218↲
7.3 Module Compilation ........................................... 222↲
7.3.1 Version Information ................................... 222↲
7.3.2 Compilation Jobs ...................................... 223↲
7.4 Creation of the DTE Module/System ............................ 224↲
↲
┆b0┆8. SOURCE TEXT ORGANIZATION ┆f0┆.......................................... 225↲
↲
┆b0┆A. REFERENCES ┆f0┆........................................................ 229↲
↲
┆b0┆B. ENVIRONMENTS ┆f0┆...................................................... 231↲
B.1 External Environments ........................................ 231↲
B.2 xdteenv ...................................................... 232↲
B.3 xx25env ...................................................... 236↲
B.4 xtraceenv .................................................... 244↲
B.5 dteenv ....................................................... 247↲
B.6 dtebreakenv .................................................. 273↲
B.7 hdlcenv ...................................................... 274↲
B.8 stdconf ...................................................... 276↲
════════════════════════════════════════════════════════════════════════
↓
┆14┆┆b3┆┆06┆v↲
↲
┆b0┆C. STATE/ACTION TABLES ┆f0┆............................................... 277↲
C.1 dte access ................................................... 277↲
C.1.1 User Dependent ........................................ 277↲
C.1.2 Stream Dependent ...................................... 279↲
C.1.3 Stream Independent .................................... 282↲
C.2 dte lcnzero .................................................. 283↲
C.3 dte chan ..................................................... 286↲
↲
┆b0┆D. TRACE AND TEST DESCRIPTION ┆f0┆........................................ 303↲
D.1 Trace Example ................................................ 304↲
D.2 Testoutput Conversion ........................................ 305↲
D.3 Testoutput Examples .......................................... 311↲
D.3.1 Process dte ........................................... 311↲
D.3.2 Process dte chan 001 .................................. 312↲
↲
┆b0┆E. CONTENTS OF LIBRARIES ┆f0┆............................................. 313↲
E.1 Lib-Files .................................................... 313↲
E.2 Plib-Files ................................................... 315↲
↲
┆b0┆F. COMPILATION EXAMPLES ┆f0┆.............................................. 317↲
F.1 Update of an Existing Binary dte ............................. 318↲
F.2 Generation of the X.25 Procedure Library ..................... 319↲
F.3 Update of the X.25 Procedure Library ......................... 320↲
F.4 Generation of the Trace System ............................... 321↲
↲
┆b0┆G. BUFFER LAYOUT IN CALL SET-UP PHASE ┆f0┆................................ 323↲
↲
┆b0┆H. INDEX ┆f0┆............................................................. 325↲
H.1 Survey of Figures ............................................ 325↲
H.2 Survey of Tables ............................................. 326↲
H.3 Survey of Examples ........................................... 327↲
════════════════════════════════════════════════════════════════════════
↓
«index» formatlinie til RC manualer↲
┆14┆┆b3┆↲
┆14┆┆b3┆┆06┆- ┆0b┆ -↲
┆a1┆┆b0┆1.╞ INTRODUCTION.↲
↲
╞ ┆84┆This paper is the reference document for the External DTE Module. ↓
┆19┆┆89┆┄┄This mo┄dule interfaces a CENTERNET Terminal Concentrator (TC) to a ↓
┆19┆┆89┆┄┄packet switched network using the CCITT recommendation X.25 (ref. ↓
┆19┆┆89┆┄┄(1)) for the communication between a TC and a network access node.↲
↲
╞ ┆84┆The module does not support the total set of functions described ↓
┆19┆┆89┆┄┄in ref. (1). The following services are ┆a1┆not┆e1┆ implemented:↲
↲
╞ - Permanent Virtual Circuit (PVC).↲
╞ - Datagram.↲
╞ - The Optional User Facilities :↲
╞ - Fast select.↲
╞ - DTE-reject.↲
↲
╞ ┆84┆Additional functions at the user interface (several simultaneous ↓
┆19┆┆89┆┄┄users, two type of user inputs) are supported.↲
↲
╞ ┆84┆The module described in this Reference Manual is level 3 of Recom┄↓
┆19┆┆89┆┄┄mendation X.25. It utilizes the RC3502 HDLC Driver (ref. (9)) to ↓
┆19┆┆89┆┄┄implement the whole recommendation.↲
↲
╞ ┆84┆The implementation of the DTE System is done in RC3502 Real-Time ↓
┆19┆┆89┆┄┄Pascal (RTP) as defined in ref. (11) to ref. (15).↲
↲
╞ ┆84┆The reader of this manual ought to be familiar with the documents ↓
┆19┆┆89┆┄┄listed in appendix A.↲
↲
↲
┆a1┆1.1╞ Structure of this Manual.↲
↲
╞ ┆84┆An overview of the RTP processes constituting the DTE System and ↓
┆19┆┆89┆┄┄its environment is described in chapter 2.↲
↲
╞ ┆84┆Chapter 3 describes the external interfaces (NCP, HDLC and User) ↓
┆19┆┆89┆┄┄very shortly and in more details the internal interfaces in the ↓
┆19┆┆89┆┄┄DTE module. This is done by describing each message received/sent ↓
┆19┆┆89┆┄┄by a process.↲
↲
┆8c┆┄┆a8┆↓
╞ ┆84┆The implementation of the DTE module on a process basis is outlin┄↓
┆19┆┆89┆┄┄ed in chapter 4.↲
↲
╞ ┆84┆Error messages produced by the DTE module are explained in chapter ↓
┆19┆┆89┆┄┄5.↲
↲
╞ ┆84┆In chapter 6 different debugging/test tools for the DTE module are ↓
┆19┆┆89┆┄┄described, nearly in the same manner as in chapter 3 and 4 for the ↓
┆19┆┆89┆┄┄DTE module.↲
↲
╞ ┆84┆In chapter 7 the configuration parameters and the compilation of ↓
┆19┆┆89┆┄┄the DTE System are described. Furthermore are the storage require┄↓
┆19┆┆89┆┄┄ments in the RC3502 calculated. This calculation is based on model ↓
┆19┆┆89┆┄┄1 (RC3502/1).↲
↲
╞ ┆84┆Finally, chapter 8 describes the source text organization in an ↓
┆19┆┆89┆┄┄RC8000.↲
↲
↲
┆a1┆1.2╞ Terminology and Notation.↲
↲
╞ ┆84┆To distinguish between a module and an RTP process (incarnation), ↓
┆19┆┆89┆┄┄a module is written with capital letters (e.g. NCP) and an RTP ↓
┆19┆┆89┆┄┄process with small letters (e.g. dte).↲
↲
╞ ┆84┆In the state/action tables the following notation is used:↲
↲
╞ _____________↲
╞ P10 ╞ ╞ P10: next state↲
╞ ┆a1┆ A1 ┆e1┆╞ ╞ A1 : action performed↲
↲
╞ ┆84┆If the state/action table is outlined as a state transition graph ↓
┆19┆┆89┆┄┄the notation is:↲
↲
╞ ┆a1┆╞ E ┆e1┆ P9 : current state↲
╞ A1 P10: next state↲
╞ P9 P10 E : event causing the transition↲
╞ ╞ ╞ ╞ A1 : action performed↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆In the figures describing message flows the following notation is ↓
┆19┆┆89┆┄┄used:↲
↲
↲
╞ ╞ ╞ ╞ a process (incarnation)↲
↲
↲
↲
↲
╞ ╞ ╞ ╞ ┆84┆a semaphore↲
╞ ╞ ╞ ╞ ┆84┆(if the semaphore is hatched then ↓
┆19┆┆a7┆┄┄the semaphore is a main semaphore)↲
↲
↲
↲
╞ ╞ ╞ ╞ signal to a semaphore↲
↲
↲
↲
╞ ╞ ╞ ╞ wait at a semaphore↲
↲
↲
↲
↲
╞ ╞ ╞ ╞ signal/wait to an internal semaphore↲
↲
↲
↲
╞ ╞ ╞ ╞ buffer pool with an access semaphore↲
════════════════════════════════════════════════════════════════════════
↓
«index» formatlinie til RC manualer↲
┆14┆┆b3┆↲
┆14┆┆b3┆┆06┆- ┆0b┆ -↲
┆b0┆┆a1┆2.╞ MODULE OVERVIEW↲
↲
╞ ┆84┆The External DTE Module consists of a number of processes, commu┄↓
┆19┆┆89┆┄┄nicating by means of internal messages.↲
↲
╞ ┆84┆Before describing each individual process some general design cri┄↓
┆19┆┆89┆┄┄teria will be outlined↲
↲
╞ ╞ ┆b0┆- ┆84┆the user interface should be identical to the user in┄↓
┆19┆┆95┆┆81┆┆82┆terface of the Internal DTE↲
↲
╞ ╞ ┆b0┆- ┆84┆the interface between the DTE and the DCE is the ↓
┆19┆┆95┆┆81┆┆82┆CCITT 1980 X.25 Recommendation (ref. (1))↲
↲
╞ ╞ ┆b0┆- ┆84┆the user interface is an open interface, which means ↓
┆19┆┆95┆┆81┆┆82┆that the DTE module has to be very robust and that the ↓
┆19┆┆95┆┆81┆┆82┆logical connections of each individual user should be ↓
┆19┆┆95┆┆81┆┆82┆independent of each other↲
↲
╞ ╞ ┆b0┆- ┆84┆only one HDLC line is used between the DTE and the DCE↲
↲
╞ ╞ ┆b0┆- ┆84┆it should be possible to connect two DTE's back to ↓
┆19┆┆95┆┆81┆┆82┆back for test purpose↲
↲
╞ ╞ ┆b0┆- ┆84┆the DTE should be able to control the modem signals↲
↲
╞ ╞ ┆b0┆- ┆84┆it should be possible to change important parameters ↓
┆19┆┆95┆┆81┆┆82┆dynamicly, at least at dte process creation.↲
↲
╞ ┆84┆All the above mentioned design criteria leads to the below de┄↓
┆19┆┆89┆┄┄scribed module structuring principle and processes.↲
↲
╞ ┆84┆One supervisor process (┆b0┆dte┆f0┆) is parent process to a number of ↓
┆19┆┆89┆┆81┆┄channel processes (┆b0┆dte_chan┆f0┆), each servicing a logical connection ↓
┆19┆┆89┆┆82┆┄(Virtual Call), a user interface process (┆b0┆dte_access┆f0┆), an HDLC in-↓
┆19┆┆89┆┆83┆┄terfacing process (┆b0┆dte_hrec┆f0┆), a channel zero process↲
┆84┆(┆b0┆dte_lcn_zero┆f0┆), and a buffer pool handler process (┆b0┆dte_pool┆f0┆). ↓
┆19┆┆89┆┆82┆┄Besides these processes the dte is parent process for four proces┄↓
┆19┆┆89┆┆82┆┄ses used as de┄bug and test tools (please refer to figure 2). ↓
════════════════════════════════════════════════════════════════════════
↓
┆19┆┆89┆┆82┆┄In figure 1 the pro┄┄cess tree of the DTE module and its environment ↓
┆19┆┆89┆┆82┆┄is shown, and in figure 2 the process tree of the debug and test ↓
┆19┆┆89┆┆82┆┄processes.↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 1: Process tree of the External DTE and its environment.↲
↲
╞ ┆84┆The channel processes are created dynamically and removed each ↓
┆19┆┆89┆┄┄time the DTE/DCE interface is restarted.↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 2: Process tree of the DTE debugging, test and trace tools.↲
↲
↲
↲
╞ ┆84┆In figure 3, 4, 5 and 6 an outline of message flow in four cases ↓
┆19┆┆89┆┄┄are presented. A more detailed description may be found in chapter ↓
┆19┆┆89┆┄┄3, whereas communication with the NCP module follows ref. (10). ↓
┆19┆┆89┆┄┄The HDLC driver interface is described in ref. (9) and the DTE ↓
┆19┆┆89┆┄┄user interface in ref. (3).↲
↲
╞ ┆84┆In the following a short description is given of the modules and ↓
┆19┆┆89┆┄┄processes found in figures 1 and 2 together with a more comprehen┄↓
┆19┆┆89┆┄┄sive description of the individual processes of the DTE System.↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆ADAM ┆84┆┆f0┆is the root of the dynamic tree of incarnations.↲
╞ ╞ ┆84┆┆a1┆ADAM┆e1┆ creates automatically three incarnations:↲
╞ ╞ ┆b0┆CONSOL↲
╞ ╞ ┆b0┆OPERATOR↲
╞ ╞ ┆b0┆S (cnadam)↲
╞ ╞ ┆a1┆ADAM┆e1┆ may remove any of the incarnations on request.↲
↲
╞ ┆b0┆OPERATOR, ┆84┆CONSOLE┆f0┆ is the interface between a human operator and ↓
┆19┆┆93┆┆81┆┄the running incarnations. ┆a1┆CONSOLE┆e1┆ performs I/O to the ↓
┆19┆┆93┆┆81┆┄debug console. ┆a1┆OPERATOR┆e1┆ processes messages signalled to ↓
┆19┆┆93┆┆81┆┄the operator semaphore.↲
↲
╞ ┆b0┆TIMER╞ ┆f0┆performs delay timing and timeout of drivers.↲
↲
╞ ADAM, OPER┆84┆ATOR, CONSOLE, and TIMER are parts of the RC3502 basic ↓
┆19┆┆93┆┄┄system (ref. (13)).↲
↲
╞ ┆b0┆cnadam╞ ┆f0┆CENTERNET parent process (ref. (8)).↲
↲
╞ ┆b0┆timeout╞ ┆84┆┆f0┆handles timer booking and timer update (ref. (6)). The ↓
┆19┆┆93┆┆81┆┄module is used by dte_chan.↲
↲
╞ ┆b0┆NCP╞ ┆a1┆┆f0┆N┆e1┆etwork ┆a1┆C┆e1┆ontrol ┆a1┆P┆e1┆robe module (ref. (10)).↲
↲
╞ ┆b0┆HDLCLCP╞ ┆84┆┆f0┆HDLC interface module. The module supervises the HDLC ↓
┆19┆┆93┆┆81┆┄driver ┆a1┆process┆e1┆ and performs all LCP operations on the ↓
┆19┆┆93┆┆81┆┄driver.↲
↲
╞ ┆b0┆dte╞ ┆84┆┆f0┆Supervisor and parent process of the DTE System. The ↓
┆19┆┆93┆┆81┆┄pro┄cess handles the DTE LCP operations (ref. (4)), some ↓
┆19┆┆93┆┆81┆┄by forwarding them to the appropriate channel process ↓
┆19┆┆93┆┆81┆┄in┄car┄nation (dte_chan<xyz>). The process also receives ↓
┆19┆┆93┆┆81┆┄LCP events and forwards these events to the NCP.↲
↲
╞ ╞ ┆84┆At Virtual Call (VC) establishment the process is active ↓
┆19┆┆93┆┄┄creating/starting a channel process incarnation and at ↓
┆19┆┆93┆┄┄VC removal stopping the incarnation.↲
↲
╞ ╞ ┆84┆In connection with dte_lcnzero the process handles the ↓
┆19┆┆93┆┄┄restart phase of the DCE/DTE interface.↲
↲
┆8c┆┄┆a9┆↓
╞ ╞ ┆84┆Furthermore, the dte controls the HDLC driver operation ↓
┆19┆┆93┆┄┄(ref. (9)) and sets/reacts on different modem signals. ↓
┆19┆┆93┆┄┄Being parent process the dte initializes common buffer ↓
┆19┆┆93┆┄┄pools, tables, and variables.↲
↲
╞ ┆b0┆dte_access┆84┆↲
┆84┆The process handles the communication to the users. ↓
┆19┆┆93┆┄┄Assignment of stream numbers and validation of user ↓
┆19┆┆93┆┄┄operations are performed by the process.↲
↲
╞ ╞ ┆84┆All user operations equal to an X.25 operation are for┄↓
┆19┆┆93┆┄┄warded to the appropriate channel process incarnation, ↓
┆19┆┆93┆┄┄whereas all other user operations are handled by the ↓
┆19┆┆93┆┄┄dte_access process itself.↲
↲
╞ ╞ ┆84┆During VC establishment the process communicates with ↓
┆19┆┆93┆┄┄the dte process in order to create/start a channel pro┄↓
┆19┆┆93┆┄┄cess incarnation.↲
↲
╞ ╞ ┆84┆Events concerning a specific stream, a user, or the DCE ↓
┆19┆┆93┆┄┄/DTE interface are received from either the dte process ↓
┆19┆┆93┆┄┄or a channel process incarnation and forwarded to the ↓
┆19┆┆93┆┄┄user of concern, or all users.↲
↲
╞ ┆b0┆dte_hrec╞ ┆84┆┆f0┆The process demuliplexes all X.25 packets received on ↓
┆19┆┆93┆┆81┆┄the hdlc line and sends the packets to the appropriate ↓
┆19┆┆93┆┆81┆┄dte_chan process incarnation or dte_lcnzero process de┄↓
┆19┆┆93┆┆81┆┄pending on the channel number. Furthermore, the process ↓
┆19┆┆93┆┆81┆┄tries to keep a specified number of input buffer at the ↓
┆19┆┆93┆┆81┆┄HDLC driver.↲
↲
╞ ╞ ┆84┆The demultiplexing function is performed utilizing a ↓
┆19┆┆93┆┄┄com┄mon table shared by the process and the dte process.↲
↲
╞ ┆b0┆dte_lcnzer┆84┆o↲
┆84┆The process handles all channel zero functions of the ↓
┆19┆┆93┆┄┄X.25 level 3 communication. The restart function/phase ↓
┆19┆┆93┆┄┄is performed in connection with the dte process and re┄↓
┆19┆┆93┆┄┄ceival of an X.25 diagnostic packet is reported to the ↓
════════════════════════════════════════════════════════════════════════
↓
┆19┆┆93┆┄┄dte process, which forwards the information furtheron to ↓
┆19┆┆93┆┄┄the NC-system (see ref. (4) and (10)).↲
↲
╞ ╞ ┆84┆The communication with the DCE is performed utilizing ↓
┆19┆┆93┆┄┄the HDLCLCP module, directly on output and via the ↓
┆19┆┆93┆┄┄dte_hrec process on input.↲
↲
╞ ┆b0┆dte_chan╞ ┆84┆┆f0┆The process handles all communication with the DCE on ↓
┆19┆┆93┆┆81┆┄X.25 level 3 except on channel zero. The dte_chan pro┄↓
┆19┆┆93┆┆81┆┄cess exists in an incarnation for every active Virtual ↓
┆19┆┆93┆┆81┆┄Call.↲
↲
╞ ╞ ┆84┆The process incarnation receives User operations from ↓
┆19┆┆93┆┄┄the dte_access process and furthermore communicates with ↓
┆19┆┆93┆┄┄this process and the dte process during Virtual Call es┄↓
┆19┆┆93┆┄┄tablishment and removal.↲
↲
╞ ╞ ┆84┆The communication to the DCE is performed utilizing the ↓
┆19┆┆93┆┄┄user interface of the HDLCLCP module ("hiding" the HDLC ↓
┆19┆┆93┆┄┄driver). Output is sent directly to the HDLCLCP whereas ↓
┆19┆┆93┆┄┄input is received through the dte_hrec process.↲
↲
╞ ┆b0┆dte_pool╞ ┆84┆┆f0┆The process maintains a pool of buffers, which are used ↓
┆19┆┆93┆┆81┆┄for X.25 control packets. A dte_chan process ↓
┆19┆┆93┆┆81┆┄incarnation, the dte or the dte_lcnzero process requests ↓
┆19┆┆93┆┆81┆┄a buffer, build up the X.25 packet and sends the buffer ↓
┆19┆┆93┆┆81┆┄to the HDLCLCP mo┄dule. The answer is returned directly ↓
┆19┆┆93┆┆81┆┄to the dte_pool pro┄cess. The dte_pool process is capable ↓
┆19┆┆93┆┆81┆┄of managing re┄quests with different priorities and may ↓
┆19┆┆93┆┆81┆┄put a request into a waiting queue, if no bufer is ↓
┆19┆┆93┆┆81┆┄available. The dte_pool is an incarnation of the ↓
┆19┆┆93┆┆81┆┄pool_handler process.↲
↲
╞ ┆b0┆dtetest╞ ┆84┆┆f0┆┆b0┆The process is not mandatory for the operation of the ↓
┆19┆┆93┆┆82┆┆82┆DTE module.┆f0┆ It is only necessary if internal testoutput ↓
┆19┆┆93┆┆82┆┄is wanted. The process allocates testoutput buffers, in┄↓
┆19┆┆93┆┆82┆┄to which a process, executing internal test, copies a test ↓
┆19┆┆93┆┆82┆┄area each time this area is full, and then the process ↓
┆19┆┆93┆┆82┆┄returns the buffer to the dtetest process.↲
↲
┆8c┆┄┆a8┆↓
╞ ╞ ┆84┆The dtetest process communicates with an operator via ↓
┆19┆┆93┆┄┄the console to start/stop internal test in different ↓
┆19┆┆93┆┄┄pro┄cesses, to switch test mode, and to start print (on ↓
┆19┆┆93┆┄┄the console) of internal testoutput. The process inter┄↓
┆19┆┆93┆┄┄prets the packed test data in a buffer and prints it in ↓
┆19┆┆93┆┄┄a more readable form on the console.↲
↲
╞ ╞ ┆84┆Furthermore, a possibility to generate test messages to ↓
┆19┆┆93┆┄┄the dte_access process and print the answer exists.↲
↲
╞ ┆b0┆dteclock┆f0┆╞ ┆84┆This process maintains a globale (in the DTE module) ↓
┆19┆┆93┆┆81┆┄"clock" used to timestamp test records, and is a child ↓
┆19┆┆93┆┆81┆┄of the dtetest process.↲
↲
╞ ┆b0┆dtetrace╞ ┆84┆┆f0┆┆b0┆The process is not mandatory for the operation of the ↓
┆19┆┆93┆┆82┆┆82┆DTE module. ┆f0┆It is only necessary if tracing of X.25 ↓
┆19┆┆93┆┆82┆┄level 3 communication is wanted.↲
↲
╞ ╞ ┆84┆The dtetrace process communicates with an operator ↓
┆19┆┆93┆┄┄via the console to set/change different trace vari┄↓
┆19┆┆93┆┄┄ables.↲
↲
╞ ╞ ┆84┆Buffers containing packed trace-data are received either ↓
┆19┆┆93┆┄┄from the dte_hrec process (trace of received packets) or ↓
┆19┆┆93┆┄┄the outtrace process (trace of transmitted packets). ↓
┆19┆┆93┆┄┄The dtetrace process prints (if required) the data on ↓
┆19┆┆93┆┄┄the console in a more readable format each time a trace ↓
┆19┆┆93┆┄┄buffer is receiv┄ed.↲
↲
╞ ┆b0┆outtrace╞ ┆84┆The process is not mandatory for the operation of the ↓
┆19┆┆93┆┆81┆┆82┆DTE module. ┆f0┆It is only necessary if tracing of X.25 ↓
┆19┆┆93┆┆81┆┄level 3 communication is wanted.↲
↲
╞ ╞ ┆84┆The only purpose of the process is to gather tracing of ↓
┆19┆┆93┆┄┄transmitted X.25 packets in one process.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆b0┆snooper╞ ┆84┆┆f0┆Parent process in the snooping system. ┆b0┆The process is ↓
┆19┆┆93┆┆82┆┆82┆not mandatory for the operation of the DTE Module. ┆f0┆It ↓
┆19┆┆93┆┆82┆┄communicates via the console with an operator to set up ↓
┆19┆┆93┆┆82┆┄parameters, to start snooping, and print snooped data. ↓
┆19┆┆93┆┆82┆┄The purpose of the snooping system is to be able to ↓
┆19┆┆93┆┆82┆┄snoop the communication to/from the dte_chan process ↓
┆19┆┆93┆┆82┆┄incarnations.↲
↲
╞ ┆b0┆pick_up╞ ┆84┆┆f0┆Performs the actual snooping of messages and answers, ↓
┆19┆┆93┆┆81┆┄and is a child of the snooper process.↲
↲
╞ ┆84┆A more detailed description of the snooping system may be found in ↓
┆19┆┆89┆┄┄ref. (7).↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 3: Message flow of normal data.↲
┆8c┆┄┆a7┆↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 4: Message flow of interrupt data.↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 5: Message flow of X.25 control packet output.↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 6: Message flow at Virtual Call Set-up.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆3.╞ PROCESS COMMUNICATION↲
↲
╞ ┆84┆In this chapter the external communication as well as the communi┄↓
┆19┆┆89┆┄┄cation between the processes constituting the DTE module are de┄↓
┆19┆┆89┆┄┄scribed. In section 3.1 the operations sent to the HDLCLCP and NCP ↓
┆19┆┆89┆┄┄modules are outlined and a short description of the DTE User In┄↓
┆19┆┆89┆┄┄terface is given. In section 3.2 the operations exchanged between ↓
┆19┆┆89┆┄┄the processes dte, dte_access, dte_hrec, dte_lcnzero, dte_chan, ↓
┆19┆┆89┆┄┄and dte_pool are described.↲
↲
╞ ┆84┆The communication and function of the dtetest system, the trace ↓
┆19┆┆89┆┄┄system, and the SNOOPER module are gathered in chapter 6.↲
↲
↲
┆a1┆3.1╞ External Communication↲
↲
╞ ┆84┆The communication external to the DTE module can shortly be de┄↓
┆19┆┆89┆┄┄scribed by figure 7.↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 7: External Interfaces of the DTE module.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆The DTE User Interface is a service provided by the DTE module, ↓
┆19┆┆89┆┄┄whereas the NCP - and HDLCLCP interfaces are services utilized by ↓
┆19┆┆89┆┄┄the DTE module.↲
↲
↲
┆a1┆3.1.1╞ DTE User Interface↲
↲
╞ ┆84┆For a detailed description of the format and function of all user ↓
┆19┆┆89┆┄┄operations please refer to ref. (3).↲
↲
╞ ┆84┆All user operations are received by the dte_access process. Some ↓
┆19┆┆89┆┄┄of the operations are returned from this process, whereas others ↓
┆19┆┆89┆┄┄are forwarded to other DTE processes. It is shown in the following ↓
┆19┆┆89┆┄┄table which process handles which user operation.↲
↲
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ ____________________________________________________________↲
╞ ! ╞ ╞ !╞ ╞ ╞ !↲
╞ ! ╞ ╞ ! handled by process !↲
╞ ┆a1┆┆e1┆! user operation ╞ ┆a1┆!╞ ╞ ╞ !↲
┆e1┆╞ !╞ ╞ ! ! !╞ !↲
╞ !╞ ╞ ! dte_access ! dte ! dte_chan !↲
╞ ┆a1┆┆a1┆!╞ ╞ ! ! ! !↲
╞ !╞ ╞ ! ! ! !↲
╞ ! dte_acc_inc_call ! + ! ! + !↲
╞ ! dte_call_req ! + ! + ! + !↲
╞ ! dte_change_mode ! + ! ! + !↲
╞ ! dte_clear_req ! + ! ! + !↲
╞ ! dte_conn_user ! + ! ! !↲
╞ ! dte_disc_user ! + ! ! !↲
╞ ! dte_rec_dedic ! + ! ! + !↲
╞ ! dte_rec_gen ! + ! ! + !↲
╞ ! dte_reset_req ! + ! ! + !↲
╞ ! dte_send_data ! + ! ! + !↲
╞ ! dte_send_intrupt ! + ! ! + !↲
╞ ! dte_sync_stream ! + ! ! + !↲
╞ ! dte_wait_event ! + ! ! !↲
╞ ┆a1┆!╞ ╞ ! ! ! !↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ Table 1: Processing of DTE User operations.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆3.1.2╞ Access to the HDLCLCP↲
↲
┆84┆The user interface of the HDLCLCP and the HDLC driver is nearly ↓
┆19┆┆89┆┄┄equal seen from the DTE. The HDLC driver interface is described in ↓
┆19┆┆89┆┄┄ref. (9). The only difference is that the driver has 4 main sema┄↓
┆19┆┆89┆┄┄phores, whereas the HDLCLCP only has one.↲
↲
╞ ┆84┆The DTE only utilizes a subset of the services provided by the ↓
┆19┆┆89┆┄┄HDLC driver. In this section an overview of the services used are ↓
┆19┆┆89┆┄┄given. A more detailed description of how the driver is used and ↓
┆19┆┆89┆┄┄how the information received from the driver influence the oper┄↓
┆19┆┆89┆┄┄ation of the DTE module is given in chapter 4.↲
↲
╞ ┆84┆Driver 'control messages' is only sent by the dte process and ↓
┆19┆┆89┆┄┄'input messages' only by the dte_hrec process. 'Output messages' ↓
┆19┆┆89┆┄┄are sent both from the processes dte, dte_lcnzero, and dte_chan ↓
┆19┆┆89┆┄┄in┄carnations. In the following table 2 the formats and contents of ↓
┆19┆┆89┆┄┄the in┄dividual messages are outlined.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Table 2: HDLC operations utilized by the DTE module.↲
════════════════════════════════════════════════════════════════════════
↓
╞ Notes:↲
↲
╞ 1)╞ ┆84┆The fully formats are defined in environment HDLCENV ↓
┆19┆┆93┆┄┄(appendix B.7).↲
↲
╞ 2)╞ The format of the data buffer is↲
╞ ╞ record↲
╞ ╞ ╞ first,last,next : integer;↲
╞ ╞ ╞ x25_packet : array (1..n) of byte;↲
╞ ╞ end;↲
╞ ╞ ╞ (* 3< = n< = 5 *)↲
↲
╞ 3)╞ ┆84┆The actual size of the input buffer is determined at ↓
┆19┆┆93┆┄┄process start up, because the X.25 user data field size ↓
┆19┆┆93┆┄┄is a process parameter of the dte process.↲
╞ ╞ input buffer size = 6 + x25_head_size + x25_packet_size↲
↲
╞ 4)╞ ┆84┆Two types of output exist↲
↲
╞ ╞ a) ┆84┆dte user data message with an dte message header ↓
┆19┆┆97┆┄┄stacked on top. This is used to transmit X.25 DATA ↓
┆19┆┆97┆┄┄packets↲
↲
╞ ╞ b) ┆84┆dte data message containing either an X.25 CALL ↓
┆19┆┆97┆┄┄REQUEST or an X.25 CALL ACCEPTED packet↲
↲
╞ ╞ The format of the latter (b) is:↲
╞ ╞ record↲
╞ ╞ ╞ first,last,next : integer;↲
╞ ╞ ╞ x25_packet : array (1..n) of byte;↲
╞ ╞ end;↲
╞ ╞ ╞ (* 3 ┆a1┆<┆e1┆ n < 98 *)↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆3.1.3╞ Access to the NCP Module↲
↲
╞ ┆84┆All communication with the NCP is performed by the dte process. ↓
┆19┆┆89┆┄┄NC-supervisor messages (DTE LCP operations) are either performed ↓
┆19┆┆89┆┄┄by the dte process or forwarded to a dte_chan process incarnation. ↓
┆19┆┆89┆┄┄Internal NC events are received by the dte process and this pro┄↓
┆19┆┆89┆┄┄cess requests then an event buffer from the NCP and herein packs ↓
┆19┆┆89┆┄┄the NC events and returns the buffer to the NCP. In figure 8 the ↓
┆19┆┆89┆┄┄communication with the NCP is outlined. A detail description of ↓
┆19┆┆89┆┄┄the NCP User Interface may be found in ref. (10), below is only ↓
┆19┆┆89┆┄┄mentioned the operations used by the DTE module.↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 8: Message flow between the DTE module and the NCP.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆At initialization the dte process connects to the NCP utilizing ↓
┆19┆┆89┆┄┄the operation↲
↲
╞ ┆a1┆┆b0┆Message name┆e1┆: connect_lcp↲
↲
╞ ┆a1┆User fields┆e1┆ : ╞ to NCP╞ from NCP↲
╞ ╞ u1 4 unch↲
╞ ╞ u2 7 result↲
╞ ╞ u3 - lcp_index↲
╞ ╞ u4 3 unch↲
↲
╞ ┆a1┆Data to NCP┆e1┆ : lcp_conn_type = record↲
╞ ╞ ╞ ╞ first,last,next : integer;↲
╞ ╞ ╞ ╞ i : bit;↲
╞ ╞ ╞ ╞ id : 0..32767;↲
╞ ╞ ╞ ╞ end;↲
↲
╞ ┆a1┆Data from NCP┆e1┆ :↲
╞ ╞ unchanged↲
↲
╞ ┆a1┆Parameters┆e1┆ : lcp_index╞ : ┆84┆value returned from the NCP and ↓
┆19┆┆a9┆┄┄used in all other communications ↓
┆19┆┆a9┆┄┄with the NCP↲
↲
╞ ╞ first,last,next: ┆84┆not used↲
↲
╞ ╞ i, id : ┆84┆set to the DTE's lcp number (2)↲
↲
╞ ╞ result ok (0) : ┆84┆the DTE is connected↲
╞ ╞ ╞ ╞ busy (2) : ┆84┆the DTE module is not ↓
┆19┆┆b3┆┄┄con┄nected to the NC-↓
┆19┆┆b3┆┄┄system, but will con┄↓
┆19┆┆b3┆┄┄tinue normal operation↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆84┆╞ ┆84┆All LCP operations are received from the NCP utilizing the ↓
┆19┆┆89┆┄┄operation↲
↲
╞ ┆a1┆┆b0┆Message name┆e1┆: wait_message↲
↲
╞ ┆a1┆User fields┆e1┆ : ╞ to NCP╞ from NCP↲
╞ ╞ u1 12 unch↲
╞ ╞ u2 7 result↲
╞ ╞ u3 lcp_index unch↲
╞ ╞ u4 3 unch↲
↲
╞ ┆a1┆Data to NCP┆e1┆ : not used↲
↲
╞ ┆a1┆Data from NCP┆e1┆ :↲
╞ ╞ unchanged↲
↲
╞ ┆a1┆Parameters┆e1┆ : lcp_index : ┆84┆the value returned in the operation ↓
┆19┆┆a5┆┄┄┆b0┆connect_lcp↲
↲
╞ ╞ result : please refer to ref. (10)↲
↲
╞ ┆84┆This message is always waiting at the NCP. The NCP returns it, ↓
┆19┆┆89┆┄┄when it has received a NC-supervisor message to the DTE. This ↓
┆19┆┆89┆┄┄message is stacked below the ┆b0┆wait_message.↲
↲
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╞ ╞ ______________↲
╞ ╞ ! dte lcp !↲
╞ ╞ ! message ! = wait_message↲
╞ ╞ ┆a1┆! header !↲
↲
↲
↲
╞ ╞ ______________ _______________↲
╞ ╞ ! NCP !╞ ! NC !↲
╞ ╞ ! message ! ! supervisor !↲
╞ ╞ ┆a1┆! header !┆e1┆ ┆a1┆! message !┆e1┆↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ ╞ NCP header:╞ from NCP╞ to NCP↲
╞ ╞ ╞ u1 15 unch↲
╞ ╞ ╞ u2 7 result↲
╞ ╞ ╞ u3 lcp_index unch↲
╞ ╞ ╞ u4 - unch↲
↲
↲
┆8c┆┄┆ac┆↓
╞ ┆84┆The dte process unstacks the dte lcp message header and sends it ↓
┆19┆┆89┆┄┄to the NCP, waiting the next NC-supervisor message. Then the re┄↓
┆19┆┆89┆┄┄ceived LCP operation (NC supervisor message) is performed.↲
↲
╞ ┆84┆Whenever an internal event is received by the dte process an event ↓
┆19┆┆89┆┄┄buffer is requested from the NCP using the operation:↲
↲
╞ ┆a1┆┆b0┆Message name┆e1┆: request_event_buffer↲
↲
╞ ┆a1┆User fields┆e1┆ : ╞ to NCP╞ from NCP↲
╞ ╞ u1 16 ╞ unch↲
╞ ╞ u2 7 result↲
╞ ╞ u3 lcp_index unch↲
╞ ╞ u4 - unch↲
↲
╞ ┆a1┆Data to NCP┆e1┆ : not used↲
↲
╞ ┆a1┆Data from NCP┆e1┆ :↲
╞ ╞ not used↲
↲
╞ ┆a1┆Parameters┆e1┆ : lcp_index : ┆84┆the value returned in the operation ↓
┆19┆┆a4┆┄┄┆b0┆connect_lcp↲
↲
╞ ╞ result : ┆84┆please refer to ref. (10)↲
↲
╞ ┆84┆When the message is returned from the NCP with result ok, an event ↓
┆19┆┆89┆┄┄buffer is stacked below.↲
↲
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╞ ╞ _____________↲
╞ ╞ ! dte lcp !↲
╞ ╞ ! message ! = request_event_buffer↲
╞ ╞ ┆a1┆! header !↲
↲
↲
╞ ╞ _____________ _______________↲
╞ ╞ ! NCP !╞ ! ┆82┆event┆81┆ !↲
╞ ╞ ! message ! ! ┆82┆buffer┆81┆ !↲
╞ ╞ ┆a1┆! header !┆e1┆╞ ┆a1┆!╞ !↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ╞ NCP header: from NCP╞ to NCP↲
╞ ╞ ╞ u1 16 unch↲
╞ ╞ u2 7 0 (= ok)↲
╞ ╞ ╞ u3 lcp_index╞ unch↲
╞ u4╞ - unch↲
↲
╞ ┆84┆The dte lcp message header is unstacked and released and the in┄↓
┆19┆┆89┆┄┄formation in the internal event is transferred (if necessary ↓
┆19┆┆89┆┄┄packed with the event 'events lost') to the event buffer and this ↓
┆19┆┆89┆┄┄message is returned to the NCP.↲
↲
╞ ┆84┆If the result is different from ok, the message header is released ↓
┆19┆┆89┆┄┄and the lost event counter is incremented by one.↲
↲
╞ ┆84┆The internal event message is returned to the event pool, which is ↓
┆19┆┆89┆┄┄a module global semaphore.↲
↲
↲
┆a1┆3.2╞ Internal Communication↲
↲
╞ ┆84┆All internal messages sent between processes in the DTE module are ↓
┆19┆┆89┆┄┄described. The messages are described under the receiving process. ↓
┆19┆┆89┆┄┄Furthermore, messages sent to a basic system or CENTERNET system ↓
┆19┆┆89┆┄┄process are mentioned in this section. All messages are given a ↓
┆19┆┆89┆┄┄mnemotecnic name used in the rest of this manual.↲
↲
╞ ┆84┆The format used to describe a message is Real-Time Pascal and the ↓
┆19┆┆89┆┄┄following notation is used↲
↲
╞ ╞ ╞ -╞ not used↲
╞ ╞ unch unchanged↲
╞ ╞ undef╞ undefined↲
↲
╞ ┆84┆In subsections 3.2.1.1 messages received are described and in ↓
┆19┆┆89┆┄┄subsec┄tions 3.2.1.2 messages sent.↲
↲
╞ ┆84┆All communication with the test, trace and debug systems are out┄↓
┆19┆┆89┆┄┄lined in chapter 6.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆3.2.1╞ Process dte↲
↲
╞ ┆84┆The following messages are handled by the dte process↲
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ name╞ ╞ sending receiving section↲
╞ ╞ ╞ process process↲
↲
╞ chan_start dte_access dte 3.2.1.1↲
╞ diag_recv dte_lcnzero dte 3.2.1.1↲
╞ int_event all dte 3.2.1.1↲
╞ restart_end dte_lcnzero dte 3.2.1.1↲
╞ restart_start╞ dte_lcnzero dte╞ 3.2.1.1↲
break_mess dte 3.2.1.1↲
↲
╞ trace_sync dte outtrace 3.2.1.2↲
╞ get_clock dte timer 3.2.1.2↲
╞ short_delay dte timer 3.2.1.2↲
↲
╞ x25_input╞ ╞ dte_hrec╞ dte 3.2.1.1↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
↲
┆a1┆3.2.1.1╞ Messages received↲
↲
╞ ┆a1┆┆b0┆Message name┆e1┆ : chan_start↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ message╞ answer↲
╞ ╞ u1 13 unch↲
╞ ╞ u2 7 result↲
╞ ╞ u3 stream_no unch↲
╞ ╞ u4 1 sem_index↲
↲
╞ ╞ buf - -↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The message is used by the dte_access process to allocate/start a ↓
┆19┆┆89┆┄┄dte_chan process incarnation for Virtual Call Set-up. Below the ↓
┆19┆┆89┆┄┄dte_access message header is a user dte_call_req stacked. The mes┄↓
┆19┆┆89┆┄┄sage header is returned with u4 set to the index of the associated ↓
┆19┆┆89┆┄┄dte_chan incarnation's main semaphore. The user dte_call_req is ↓
┆19┆┆89┆┄┄forwarded to the dte_chan incarnation's main semaphore.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆a1┆Result┆e1┆:↲
╞ ok (0): only header returned, u4 = sem_index↲
╞ busy (2): ┆84┆no resources in the dte, either logical ↓
┆19┆┆a0┆┄┄channels or dte_chan incarnations. Stacked ↓
┆19┆┆a0┆┄┄message returned and u4 is unchanged.↲
╞ dte_restarted (98): ┆84┆the DTE has been restarted. Stacked message ↓
┆19┆┆a0┆┄┄returned and u4 is unchanged.↲
↲
╞ ┆a1┆┆b0┆Message name┆e1┆: diag_recv↲
↲
╞ ┆a1┆Message format┆e1┆:↲
╞ ╞ message╞ answer↲
╞ ╞ u1 228 unch↲
╞ ╞ u2 7 result↲
╞ ╞ u3 - unch↲
╞ ╞ u4 2 unch↲
↲
╞ ╞ buf diag_type unch↲
↲
╞ ╞ diag_type = record↲
╞ ╞ ╞ diag_code : byte;↲
╞ ╞ ╞ expl : array (0..2) of byte;↲
╞ ╞ ╞ end;↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆An X.25 DIAGNOSTIC packet has been received by the dte_lcnzero ↓
┆19┆┆89┆┄┄pro┄cess. Information about this event and the data field is for┄↓
┆19┆┆89┆┄┄warded to the dte process using this message.↲
↲
╞ ┆84┆The dte generates an NC event, increments a statistic counter and ↓
┆19┆┆89┆┄┄returns the message.↲
↲
╞ ┆a1┆Result┆e1┆:↲
╞ ok╞ (0): message processed properly↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ┆a1┆Message name┆e1┆ : int_event↲
↲
╞ ┆a1┆Message format┆e1┆:↲
╞ ╞ message↲
╞ ╞ u1 -↲
╞ ╞ u2 -↲
╞ ╞ u3 -↲
╞ ╞ u4 10↲
↲
╞ ╞ buf event_rec↲
↲
╞ ╞ event_rec = record↲
╞ ╞ ╞ head : ev_head;↲
╞ ╞ ╞ data : event_data;↲
╞ ╞ ╞ end;↲
↲
╞ ╞ ev_head = record↲
╞ ╞ ╞ event_type : byte;↲
╞ ╞ ╞ bytecount : byte;↲
╞ ╞ ╞ end;↲
↲
╞ ╞ event_data = array (1..event_length) of byte;↲
↲
╞ ╞ event_length = 87;↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The message passes an event to the dte process. The event is for┄↓
┆19┆┆89┆┄┄warded to the NCP (please refer to subsection 3.1.3) and the mes┄↓
┆19┆┆89┆┄┄sage is returned to the internal event pool. This event pool is ↓
┆19┆┆89┆┄┄represented by the module global semaphore event_pool.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ┆a1┆Message name┆e1┆ : restart_end↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ message╞ answer↲
╞ ╞ u1 248 unch↲
╞ ╞ u2 conn_seq_no result↲
╞ ╞ u3 reason unch↲
╞ ╞ u4 2 unch↲
↲
╞ ╞ buf cd_buf_type╞ unch↲
↲
╞ ╞ cd_buf_type = record↲
╞ ╞ ╞ cause,↲
╞ ╞ ╞ diag_code : byte;↲
╞ ╞ ╞ end;↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The dte_lcnzero process indicates to the dte process that a re┄↓
┆19┆┆89┆┄┄start phase is ended, or a timeout (DTE waiting restart confirma┄↓
┆19┆┆89┆┄┄tion) has occured.↲
↲
╞ ┆84┆conn_seq_no is the last received (by dte_lcnzero) connection ↓
┆19┆┆89┆┄┄sequence number.↲
↲
╞ ┆84┆reason indicates the event that causes the submission of the ↓
┆19┆┆89┆┄┄message:↲
↲
╞ 0 : DTE is the initiator of the restart phase↲
╞ 1 : DCE is the initiator↲
╞ 10 : a restart timeout has occured↲
↲
╞ ┆a1┆Result┆e1┆:↲
╞ ok (0) : message processed properly↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆a1┆┆b0┆Message name┆e1┆ : break_mess↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ message↲
╞ ╞ u1 -↲
╞ ╞ u2 -↲
╞ ╞ u3 -↲
╞ ╞ u4 15↲
↲
╞ ╞ buf break_type↲
↲
╞ ╞ break_type = record↲
╞ ╞ ╞ name : alfa;↲
╞ ╞ ╞ break_code : integer;↲
╞ ╞ ╞ vers : byte;↲
╞ ╞ ╞ end;↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆A child process (dte_chan, dte_lcnzero, dtetrace) has entered its ↓
┆19┆┆89┆┄┄exception procedure and indicates this to the dte process by ↓
┆19┆┆89┆┄┄sending this message. name is the name of the failing process ↓
┆19┆┆89┆┄┄and vers is the version identification if any. Break_code is the ↓
┆19┆┆89┆┄┄type of exception, except the value 90 which is used to break a ↓
┆19┆┆89┆┄┄process in order to get the last generated testoutput. In the lat┄↓
┆19┆┆89┆┄┄ter case the message is sent from the dtetest process. If the mes┄↓
┆19┆┆89┆┄┄sage is received from the dte_chan process a ┆b0┆sync_mess┆f0┆ (subsec┄tion ↓
┆19┆┆89┆┆81┆┄3.2.5.1) may be stacked below.↲
↲
╞ ┆84┆The message is returned to the dte global known semaphore ↓
┆19┆┆89┆┄┄breaksem.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ┆a1┆Message name┆e1┆ : x25_input↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ received answer↲
╞ ╞ u1 1↲
╞ ╞ u2 0↲
╞ ╞ u3 -↲
╞ ╞ u4 6↲
↲
╞ ╞ buf x25_buf_type↲
↲
╞ ╞ x25_buf_type = record↲
╞ ╞ ╞ first,last,next: integer;↲
╞ ╞ ╞ head : x25_head;↲
╞ ╞ ╞ data : array (first+3..last);↲
╞ ╞ ╞ end;↲
↲
╞ ╞ x25_head = packed record↲
╞ ╞ ╞ q_bit,↲
╞ ╞ ╞ d_bit,↲
╞ ╞ ╞ m128,↲
╞ ╞ ╞ m8 : bit;↲
╞ ╞ ╞ lcgn : bit4;↲
╞ ╞ ╞ lcn ╞ : byte;↲
╞ ╞ ╞ packet_id╞ : byte;↲
╞ ╞ ╞ end;↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The buffer is received from the dte_hrec process. It contains a ↓
┆19┆┆89┆┄┄received X.25 packet on a logical channel, which not yet has been ↓
┆19┆┆89┆┄┄set up. The packet type is identified and if it is an INCOMING ↓
┆19┆┆89┆┄┄CALL a Call Set-up phase is entered. All other packets are for┄↓
┆19┆┆89┆┄┄warded to the associated dte_chan process incarnation, and in case ↓
┆19┆┆89┆┄┄the channel is not set up the dte either clears the channel or ↓
┆19┆┆89┆┄┄dis┄cards the packet.↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆3.2.1.2╞ Messages sent↲
↲
╞ ┆84┆The next three messages are both sent and received by the dte ↓
┆19┆┆89┆┄┄process. It is internal communication or external communication ↓
┆19┆┆89┆┄┄not described in section 3.1.↲
↲
┆b0┆╞ ┆a1┆Message name┆e1┆ : trace_sync↲
↲
╞ ┆a1┆Message format┆a1┆┆e1┆ : ↲
╞ ╞ message sent╞ answer recv.↲
╞ ╞ u1 255 unch↲
╞ ╞ u2 - unch↲
╞ ╞ u3 -╞ unch↲
╞ ╞ u4 - ╞ unch↲
↲
╞ ╞ buf -╞ unch↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The message is sent to the outtrace process to synchronize the ↓
┆19┆┆89┆┄┄two processes in case the Trace System has to be removed.↲
↲
┆b0┆╞ ┆a1┆Message name┆e1┆ : get_clock↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ message sent answer recv.↲
╞ ╞ u1╞ 1╞ unch↲
╞ ╞ u2╞ -╞ 0↲
╞ ╞ u3 - 0↲
╞ ╞ u4 - unch↲
↲
╞ ╞ buf╞ - delaytype↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ╞ delaytype = record↲
╞ ╞ ╞ prev_date : coded_date;↲
╞ ╞ ╞ prev_time : coded_time;↲
╞ ╞ ╞ prev_secs : coded_secs;↲
╞ ╞ ╞ inc : packed record↲
╞ ╞ ╞ ╞ days : 0..63;↲
╞ ╞ ╞ ╞ hours : 0..31;↲
╞ ╞ ╞ ╞ mins : 0..63;↲
╞ ╞ ╞ ╞ secs : 0..63;↲
╞ ╞ ╞ ╞ msecs : 0..1023;↲
╞ ╞ ╞ ╞ end;↲
╞ ╞ ╞ end;↲
↲
╞ ┆84┆The type definition of coded_date, coded_time, and coded_secs may ↓
┆19┆┆89┆┄┄be found in the RTP standard environment.↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The dte process requests the timer process to return the date and ↓
┆19┆┆89┆┄┄time. These are used as time stamp on console output.↓
↲
↲
┆b0┆╞ ┆a1┆Message name┆e2┆┆e1┆ : short_delay↲
↲
╞ ┆a1┆Message format┆e1┆ :↲
╞ ╞ message sent answer recv.↲
╞ ╞ u1 5 unch↲
╞ ╞ u2 60 result↲
╞ ╞ u3 10╞ 0↲
╞ ╞ u4 5╞ unch↲
↲
╞ ╞ buf╞ -╞ unch↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The dte process requests the timer process to return the message ↓
┆19┆┆89┆┄┄after 60 * 2 ** 10 msecs. (= 61,44 secs). The result may either be ↓
┆19┆┆89┆┄┄ok or regretted, but the dte does not regret this message. The ↓
┆19┆┆89┆┄┄timer periode is used in the hdlc connection and modem signals set ↓
┆19┆┆89┆┄┄up phases, to give a suitable periode between retries.↲
↲
╞ ┆a1┆Result┆e1┆:↲
╞ ┆84┆ok (0) : message processed properly↲
╞ sys_not_processed (1) : message regretted.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆a1┆3.2.2╞ Process dte_access↲
↲
╞ ┆84┆The following internal messages are handled by the dte_access ↓
┆19┆┆89┆┄┄process.↲
↲
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╞ name╞ ╞ sending receiving section↲
╞ ╞ ╞ process╞ process↲
↲
╞ clear_event dte_chan╞ dte_access 3.2.2.1↲
╞ inc_call dte_chan╞ dte_access 3.2.2.1↲
╞ inc_s_event╞ dte_chan dte_access 3.2.2.1↲
╞ inc_u_event╞ dte_chan dte_access 3.2.2.1↲
╞ restart_end╞ dte dte_access 3.2.2.1↲
╞ restart_start dte╞ dte_access 3.2.2.1↲
╞ stream_cleared dte_chan╞ dte_access 3.2.2.1↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ ┆84┆Besides these messages the dte_access process receives all user ↓
┆19┆┆89┆┄┄messages (ref. (3)) and either reacts on these or forwards them ↓
┆19┆┆89┆┄┄to a dte_chan process incarnaion (please refer to subsection ↓
┆19┆┆89┆┄┄3.1.1).↲
↲
↲
┆a1┆3.2.2.1╞ Messages received↲
↲
╞ ┆a1┆┆b0┆Message name┆e1┆ : clear_event↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ message╞ answer↲
╞ ╞ u1 22 unch↲
╞ ╞ u2 15╞ result↲
╞ ╞ u3 stream_no unch↲
╞ ╞ u4 0╞ unch↲
↲
╞ ╞ buf ch_ev_data unch↲
↲
╞ ╞ ch_ev_data = record↲
╞ ╞ ╞ first,last,next : integer;↲
╞ ╞ ╞ gen_u_event : boolean;↲
╞ ╞ ╞ type_event,↲
╞ ╞ ╞ cause,↲
╞ ╞ ╞ diag_code : byte;↲
╞ ╞ ╞ end;↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆Clearing of the stream is started. If gen_u_event is true the user ↓
┆19┆┆89┆┄┄is informed about the clearing of the stream, including a cause ↓
┆19┆┆89┆┄┄and a diagnostic code (diag_code) if any.↲
↲
╞ ┆a1┆Result┆e1┆:↲
╞ ok (0) : message processed properly↲
╞ fct_not_allw (12) : function not allowed in this state↲
╞ dte_restarted (98) : dte_access in restart phase↲
↲
╞ ┆84┆If the dte_access process is awaiting a user accept/reject of an ↓
┆19┆┆89┆┄┄incoming call on this stream, the dte_chan buffer indicating the ↓
┆19┆┆89┆┄┄call (please see ┆b0┆inc_call ┆f0┆below) is stacked below and returned ↓
┆19┆┆89┆┆81┆┄together with the ┆b0┆clear_event┆f0┆ message.↲
↲
╞ ┆a1┆┆b0┆Message name┆e1┆ : inc_call↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ message╞ answer↲
╞ ╞ u1 19 unch↲
╞ ╞ u2 15 result↲
╞ ╞ u3 sem_index stream_no/unch↲
╞ ╞ u4 0╞ unch↲
↲
╞ ╞ buf see below unch↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆An X.25 INCOMING CALL packet is received by a dte_chan process ↓
┆19┆┆89┆┄┄incarnation. The dte_access process is informed and call_data is ↓
┆19┆┆89┆┄┄contained in the message (see below) and transferred to the user, ↓
┆19┆┆89┆┄┄together with an allocated stream number.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆The message is very complex, it actually consists of three mes┄↓
┆19┆┆89┆┄┄sages:↲
↲
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╞ ╞ ________________↲
╞ ╞ ! !↲
╞ ╞ ! internal 1 !↲
╞ ╞ ┆a1┆!╞ !↲
↲
↲
╞ ╞ ________________ _______________↲
╞ ╞ !╞ ! !╞ !↲
╞ ╞ ! internal 2 !╞ ! data 2 !↲
╞ ╞ ┆a1┆! !┆e1┆╞ ┆a1┆! !↲
↲
↲
╞ ╞ ________________ _______________↲
╞ ╞ ! ! ! !↲
╞ ╞ ! user ! ! data 3 !↲
╞ ╞ ┆a1┆!╞ !┆e1┆ ┆a1┆! !↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ ┆84┆The message header 'internal 1' is described above and is returned ↓
┆19┆┆89┆┄┄immediately with result set to:↲
↲
╞ ╞ 0 : ┆84┆action performed, message not stacked,↲
╞ ╞ u3 = allocated stream number↲
↲
╞ ╞ 2 : busy = no internal resources in dte_access,↲
╞ ╞ message stacked (internal 1, internal 2, user),↲
╞ ╞ u3 = unch↲
↲
╞ ╞ 98 : dte_access in restart phase, message stacked↲
╞ ╞ (internal 1, internal 2, user)↲
╞ ╞ u3 = unch↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆The message internal 2 has the following user fields:↲
↲
╞ ╞ message╞ answer↲
╞ u1╞ 19╞ unch ↲
╞ u2╞ 15 result2↲
╞ u3╞ -╞ stream_no/diag_code/unch↲
╞ u4 0╞ unch↲
↲
╞ buf╞ call_adr_buf accept_data↲
↲
╞ call_adr_buf = record↲
╞ ╞ first,last,next : integer;↲
╞ ╞ user_address : ┆84┆packed array (1..(xhead_call-6) ↓
┆19┆┆ac┆┄┄*2) of bit4;↲
╞ ╞ pkt_head : dte_head_type;↲
╞ ╞ addr_lgth : byte;↲
╞ ╞ dte_adr : array (1..14) of byte;↲
╞ ╞ end;↲
↲
╞ xhead_call = 10 (* please see appendix B.2 *)↲
↲
╞ dte_head_type = packed record↲
╞ ╞ q_bit,↲
╞ ╞ d_bit : bit;↲
╞ ╞ ? : 0..63;↲
╞ ╞ ? : byte;↲
╞ ╞ ? : 0..7;↲
╞ ╞ m_bit : bit;↲
╞ ╞ ? : 0..15;↲
╞ ╞ end,↲
↲
╞ ┆84┆This message is hung up in the dte_access process until the user ↓
┆19┆┆89┆┄┄accepts or rejects the received call-set up or a ┆b0┆clear_event┆f0┆ is ↓
┆19┆┆89┆┆81┆┄received from the dte_chan process incarnation. In the first case ↓
┆19┆┆89┆┆81┆┄the message is returned stacked with the user accept message and ↓
┆19┆┆89┆┆81┆┄if the user has requested any X.25 facilities, this request is ↓
┆19┆┆89┆┆81┆┄transferred from the user accept message to the data buffer ↓
┆19┆┆89┆┆81┆┄'data 2', which at return has the following format:↲
════════════════════════════════════════════════════════════════════════
↓
╞ ╞ accept_data = record↲
╞ ╞ ╞ first,last,next : integer;↲
╞ ╞ ╞ user_address : ┆84┆packed array ↓
┆19┆┆b5┆┄┄(1..(xhead_call-6) *2 ↓
┆19┆┆b5┆┄┄of bit4;↲
╞ ╞ ╞ pkt_head : dte_head_type;↲
╞ ╞ ╞ addr_lgth : byte;↲
╞ ╞ ╞ dte_adr : array (1..14) of byte;↲
╞ ╞ ╞ faci_length : byte;↲
╞ ╞ ╞ facilities : ┆84┆array (xhead_call + ↓
┆19┆┆b5┆┄┄19..last) of byte;↲
╞ ╞ ╞ end;↲
↲
╞ ┆84┆In the second case the message is returned with user fields set ↓
┆19┆┆89┆┄┄according to the user reject. The data is not changed. In the ↓
┆19┆┆89┆┄┄third case the message is returned, stacked below the ┆b0┆clear_event┆f0┆ ↓
┆19┆┆89┆┆81┆┄message, and the header and data part are unchanged. The following ↓
┆19┆┆89┆┆81┆┄table gives an overview of the possibilities.↲
↲
╞ u2 = result2╞ message stack╞ ╞ u3↲
↲
╞ 0 (ok)╞ ╞ mess stacked with╞ stream_no↲
╞ ╞ ╞ user accept↲
↲
╞ 28 (buf_lgth_err)╞ mess stacked with╞ stream_no↲
╞ ╞ ╞ user accept↲
↲
╞ 91 (user_reject)╞ mess not stacked ╞ diagnostic code↲
↲
╞ 98 (dte_restarted) mess not stacked╞ ╞ unch↲
↲
╞ unch╞ ╞ mess stacked below╞ unch↲
╞ ╞ ╞ ┆b0┆clear_event┆f0┆ message↲
↲
╞ ┆84┆The message 'user' is a general input buffer containing call data ↓
┆19┆┆89┆┄┄to the user. The return of this message to the user is an indica┄↓
┆19┆┆89┆┄┄tion of the receival of an X.25 INCOMING CALL packet. The format ↓
┆19┆┆89┆┄┄of the message is described in ref. (3).↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆a1┆┆b0┆Message name┆e1┆ : inc_s_event↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ message╞ answer↲
╞ ╞ u1 20 unch↲
╞ ╞ u2 15 result↲
╞ u3 stream_no╞ unch↲
╞ ╞ u4 0╞ unch↲
↲
╞ ╞ buf ch_ev_data unch↲
↲
╞ ╞ ch_ev_data = record↲
╞ ╞ ╞ first,last,next : integer;↲
╞ ╞ ╞ gen_u_event : boolean;↲
╞ ╞ ╞ type_event,↲
╞ ╞ ╞ cause,↲
╞ ╞ ╞ diag_code : byte;↲
╞ ╞ ╞ end;↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The message contains a stream event (reset, data lost, inter┄rupt ↓
┆19┆┆89┆┄┄lost) which depending on the value of gen_u_event is transferred ↓
┆19┆┆89┆┄┄to the user in a user wait_event message.↲
↲
╞ ┆a1┆Result┆e1┆:↲
╞ ok (0) : message processed properly↲
╞ fct_not_allw (12) : function not allowed in this state↲
╞ dte_restarted (98) : dte_access in restart phase↲
↲
↲
╞ ┆b0┆┆a1┆Message name┆e1┆ : inc_u_event↲
↲
╞ ┆a1┆Message format┆e1┆:↲
╞ ╞ message╞ answer↲
╞ ╞ u1 21╞ unch↲
╞ ╞ u2 15╞ result↲
╞ ╞ u3 user_no╞ unch↲
╞ ╞ u4 0╞ unch↲
↲
╞ ╞ buf ch_ev_data╞ unch↲
════════════════════════════════════════════════════════════════════════
↓
╞ ╞ ch_ev_data = record↲
╞ ╞ ╞ first,last next : integer;↲
╞ ╞ ╞ gen_u_event : boolean;↲
╞ ╞ ╞ type_event,↲
╞ ╞ ╞ cause,↲
╞ ╞ ╞ diag_code : byte;↲
╞ ╞ ╞ end;↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The message indicates a user event (incoming call lost) which is ↓
┆19┆┆89┆┄┄transferred to the user in a user wait_event message.↲
↲
╞ ┆a1┆Result┆e1┆:↲
╞ ok (0) : ok↲
╞ dte_restarted (98) : dte_access in restart phase↲
↲
╞ ┆a1┆┆b0┆Message name┆e1┆ : restart_end↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ message╞ answer↲
╞ ╞ u1 248╞ unch↲
╞ ╞ u2 15╞ 0↲
╞ ╞ u3 ok/timeout╞ unch↲
╞ ╞ u4 8╞ unch↲
↲
╞ ╞ buf cd_buf_type╞ unch↲
↲
╞ cd_buf_type = record↲
╞ ╞ cause,↲
╞ ╞ diag_code : byte;↲
╞ ╞ end;↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The dte process indicates the ending of a restart phase or a time┄↓
┆19┆┆89┆┄┄out. The user is informed by the return of a user wait_event mes┄↓
┆19┆┆89┆┄┄sage with event_type 'dte_restarted' or 'disconnected', respecti┄↓
┆19┆┆89┆┄┄vely. If u3 = timeout (10) the dte_access stays in the dte_restart ↓
┆19┆┆89┆┄┄phase. The message is returned immediately.↲
↲
┆8c┆┄┆a7┆↓
┆b0┆╞ ┆a1┆Message name┆e1┆ : restart_start↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ message╞ answer↲
╞ ╞ u1 252╞ unch↲
╞ ╞ u2 15╞ 0↲
╞ ╞ u3 cause╞ unch↲
╞ ╞ u4 8╞ unch↲
↲
╞ ╞ buf cd_buf_type unch↲
↲
╞ ╞ cd_buf_type = record↲
╞ ╞ ╞ cause,↲
╞ ╞ ╞ diag_code : byte;↲
╞ ╞ ╞ end;↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The dte process indicates the start of a restart phase (cause = 2) ↓
┆19┆┆89┆┄┄or the disconnection of the hdlc line (cause = 1). The dte_access ↓
┆19┆┆89┆┄┄process transfers this information to the user utilizing the ↓
┆19┆┆89┆┄┄wait_event message and enters the state dte_restart. The ┆b0┆re┄↓
┆19┆┆89┆┆81┆┆82┆start_start┆f0┆ message is returned immediately.↲
↲
╞ ┆a1┆┆b0┆Message name┆e1┆ : stream_cleared↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ message╞ answer↲
╞ ╞ u1 23 ╞ unch↲
╞ ╞ u2 15╞ result↲
╞ ╞ u3 stream_no╞ unch↲
╞ ╞ u4 0╞ unch↲
↲
╞ ╞ buf -╞ -↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆A dte_chan process incarnation indicates the end of a clear phase. ↓
┆19┆┆89┆┄┄All user buffers are returned and the state of the stream is ↓
┆19┆┆89┆┄┄changed to idle.↲
↲
┆8c┆┄┆a7┆↓
╞ ┆a1┆Result┆e1┆:↲
╞ ok (0) : message processed properly↲
╞ fct_not_allw (12) : function not allowed in this state↲
╞ dte_restarted (98) : dte_access in restart phase↲
↲
↲
┆a1┆3.2.3╞ Process dte_hrec↲
↲
╞ ┆84┆The following internal messages are handled by the dte_hrec ↓
┆19┆┆89┆┄┄process.↲
↲
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╞ name╞ sending╞ receiving╞ section↲
╞ ╞ process╞ process↲
↲
╞ set_ass_chan dte dte_hrec╞ 3.2.3.1↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
↲
┆a1┆3.2.3.1╞ Messages received↲
↲
┆b0┆╞ ┆a1┆Message name┆e1┆ : set_ass_chan↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ message╞ answer↲
╞ ╞ u1 6╞ unch↲
╞ ╞ u2╞ 7 ╞ result↲
╞ ╞ u3 -╞ unch↲
╞ ╞ u4 8╞ unch↲
↲
╞ ╞ buf sup_mess_type╞ unch↲
↲
╞ ╞ sup_mess_type = record↲
╞ ╞ ╞ x25_var : x25_rec_type;↲
╞ ╞ ╞ in_buf : byte;↲
╞ ╞ ╞ end;↲
↲
╞ ╞ x25_rec_type = record↲
╞ ╞ ╞ ltc,↲
╞ ╞ ╞ htc : channel_type;↲
╞ ╞ ╞ ltci,↲
╞ ╞ ╞ htci : integer;↲
╞ ╞ ╞ end;↲
↲
┆8c┆┄┆aa┆↓
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The assigned logical channel interval, the lowest and highest ↓
┆19┆┆89┆┄┄index to the dte_chan process semaphore array, and the number of ↓
┆19┆┆89┆┄┄input buffers at the HDLC driver are set/updated.↲
↲
╞ ┆84┆The maximum number of hdlc input buffers is set to 10 in the ↓
┆19┆┆89┆┄┄environment DTEENV (appendix B.5).↲
↲
╞ ┆84┆The consistens of the parameters is checked and if not ok, the ↓
┆19┆┆89┆┄┄message is returned with 'format_error'. The following rules have to ↓
┆19┆┆89┆┄┄be observed:↲
↲
╞ 1)╞ htci-ltci ┆a1┆<┆e1┆ max channels↲
╞ 2)╞ ltci ┆a1┆<┆e1┆ htci↲
╞ 3)╞ n_buf ┆a1┆<┆e1┆ max_inbufs (=10)↲
↲
╞ ┆a1┆Result┆e1┆:↲
╞ ok (0) : variable updated↲
╞ format_err (20) : variable error↲
↲
↲
┆a1┆3.2.4╞ Process dte_lcnzero↲
↲
╞ ┆84┆The following internal/external messages are handled by the ↓
┆19┆┆89┆┄┄dte_lcnzero process.↲
↲
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╞ name╞ sending╞ receiving╞ section↲
╞ ╞ process╞ process↲
↲
╞ hdlc_conn dte╞ ╞ dte_lcnzero╞ 3.2.4.1↲
╞ hdlc_disc╞ dte╞ ╞ dte_lcnzero╞ 3.2.4.1↲
╞ restart_start dte╞ ╞ dte_lcnzero╞ 3.2.4.1↲
↲
╞ l_rel_delay dte_lcnzero╞ timer╞ 3.2.4.2↲
╞ regret╞ dte_lcnzero╞ timer╞ 3.2.4.2↲
↲
╞ x25_input dte_hrec╞ dte_lcnzero╞ 3.2.4.1↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆3.2.4.1╞ Messages received↲
↲
┆b0┆╞ ┆a1┆Message name┆e1┆ : hdlc_conn↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ message╞ answer↲
╞ ╞ u1 4╞ unch↲
╞ ╞ u2 7╞ result↲
╞ ╞ u3 conn_seq_no unch↲
╞ ╞ u4 8╞ unch↲
↲
╞ ╞ buf╞ -╞ unch↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The HDLC line has been connected. The internal state is changed to ↓
┆19┆┆89┆┄┄hdlc_active.↲
↲
╞ ┆84┆An X.25 RESTART REQUEST is expected to have been transmitted to ↓
┆19┆┆89┆┄┄the DCE from the dte process, so the timer t20 is started. Connec┄↓
┆19┆┆89┆┄┄tion number is set to the value of the u3 field.↲
↲
╞ ┆a1┆Result┆e1┆:↲
╞ ok╞ (0) : message processed properly↲
↲
┆b0┆╞ ┆a1┆Message name┆e1┆ : hdlc_disc↲
↲
╞ ┆a1┆Message format┆e1┆: ↲
╞ ╞ message╞ answer↲
╞ ╞ u1 8╞ unch↲
╞ ╞ u2 7╞ result↲
╞ ╞ u3 0╞ unch↲
╞ ╞ u4 8╞ unch↲
↲
╞ ╞ buf -╞ unch↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The hdlc line has been discconnected. The internal state is set to ↓
┆19┆┆89┆┄┄net_down. If timer t20 is running, it is stopped by a regret ↓
┆19┆┆89┆┄┄message.↲
↲
╞ ┆a1┆Result┆e1┆:↲
╞ ok╞ (0): message processed properly↲
↲
┆b0┆╞ ┆a1┆Message name┆e1┆ : restart_start↲
↲
╞ ┆a1┆Message format┆e1┆: ↲
╞ ╞ message╞ answer↲
╞ ╞ u1 252╞ unch↲
╞ ╞ u2 ╞ 7╞ result↲
╞ ╞ u3 diag_code╞ unch↲
╞ ╞ u4 8╞ unch↲
↲
╞ ╞ buf╞ -╞ unch↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆A restart phase is requested by the dte process. The internal sta┄↓
┆19┆┆89┆┄┄te is set to dte_restart. An X.25 RESTART REQUEST is transmit┄↓
┆19┆┆89┆┄┄ted to the DCE and timer t20 is started. Octet 4 in the RESTART ↓
┆19┆┆89┆┄┄REQUEST is set to 0 and octet 5 to diag_code (u3 field).↲
↲
╞ ┆a1┆Result┆e1┆:↲
╞ ok╞ (0) : message processed properly↲
╞ rejected (17) : ┆84┆the DTE/DCE interface is already in the restart ↓
┆19┆┆9a┆┄┄phase.↲
↲
┆b0┆╞ ┆a1┆Message name┆e1┆ : x25_input↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ received answer↲
╞ ╞ u1 1↲
╞ ╞ u2 0↲
╞ ╞ u3╞ -↲
╞ ╞ u4╞ 6↲
↲
╞ ╞ buf x25_buf_type↲
════════════════════════════════════════════════════════════════════════
↓
╞ ╞ x25_buf_type = record↲
╞ ╞ ╞ first,last,next : integer;↲
╞ ╞ ╞ head╞ ╞ : x25_head;↲
╞ ╞ ╞ data╞ ╞ : ┆84┆array ↓
┆19┆┆be┆┄┄(first+3..last) ↓
┆19┆┆be┆┄┄of byte;↲
╞ ╞ ╞ end;↲
↲
╞ ╞ x25_head = packed record↲
╞ ╞ ╞ q_bit,↲
╞ ╞ ╞ d_bit,↲
╞ ╞ ╞ m128,↲
╞ ╞ ╞ m8 : bit;↲
╞ ╞ ╞ lcgn╞ : bit4;↲
╞ ╞ ╞ lcn╞ : byte;↲
╞ ╞ ╞ packet_id╞ : byte;↲
╞ ╞ ╞ end;↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The buffer is received from the dte_hrec process. It contains a ↓
┆19┆┆89┆┄┄received X.25 packet on logical channel zero (lcgn = 0 and lcn = ↓
┆19┆┆89┆┄┄0). The packet type is identified and put into one of four groups:↲
↲
╞ a)╞ ┆b0┆restart indication:↲
╞ ╞ ┆84┆either the restart phase is ended or a new is initiated ↓
┆19┆┆93┆┄┄by the DCE. In the first case timer t20 is stopped and ↓
┆19┆┆93┆┄┄the internal state is changed to dte_ready. In the last ↓
┆19┆┆93┆┄┄case a RESTART CONFIRMATION is transmitted to the DCE. ↓
┆19┆┆93┆┄┄In both cases the dte process is informed↲
↲
╞ b)╞ ┆84┆┆b0┆restart confirmation:↲
╞ ╞ ┆84┆the restart phase is ended by the DCE. The dte process ↓
┆19┆┆93┆┄┄is informed and timer t20 is stopped and the internal ↓
┆19┆┆93┆┄┄state is changed to dte_ready↲
↲
╞ c)╞ ┆b0┆diagnostic:↲
╞ ╞ ┆84┆the dte process is informed↲
↲
╞ d)╞ ┆b0┆all others:↲
╞ ╞ ┆84┆the packet is just discarded↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆3.2.4.2╞ Messages sent↲
↲
╞ ┆84┆The next two messages are used in connection with timer t20 and ↓
┆19┆┆89┆┄┄are both sent and received by the dte_lcnzero process.↲
↲
╞ ┆a1┆┆b0┆Message name┆e1┆ : l_rel_delay↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ message sent╞ answer received↲
╞ ╞ u1 9╞ ╞ unch↲
╞ ╞ u2╞ 7╞ result↲
╞ ╞ u3╞ -╞ ╞ 0↲
╞ ╞ u4╞ 5╞ ╞ unch ↲
↲
╞ ╞ buf delaytype╞ ╞ ?↲
↲
╞ ╞ delaytype = record↲
╞ ╞ ╞ prev_date : coded_date;↲
╞ ╞ ╞ prev_time : coded_time;↲
╞ ╞ ╞ prev_secs : coded_secs;↲
╞ ╞ ╞ inc╞ : packed record↲
╞ ╞ ╞ ╞ days : 0..63;↲
╞ ╞ ╞ ╞ hours : 0..31;↲
╞ ╞ ╞ ╞ mins : 0..63;↲
╞ ╞ ╞ ╞ secs : 0..63;↲
╞ ╞ ╞ ╞ msecs : 0..1023;↲
╞ ╞ ╞ ╞ end;↲
╞ ╞ ╞ end;↲
↲
╞ ┆84┆The type definition of coded_date, coded_time, and coded_secs may ↓
┆19┆┆89┆┄┄be found in the RTP standard environment.↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The dte_lcnzero process requests the timer process to return the ↓
┆19┆┆89┆┄┄message after the time specified in the record inc. The default ↓
┆19┆┆89┆┄┄value used in the X.25 recommendation is 180 seconds.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆a1┆Result┆e1┆:↲
╞ ok (0) : the timer period has elapsed↲
╞ sys_not_processed (1) : the message has been regretted↲
↲
┆b0┆╞ ┆a1┆Message name┆e1┆ : regret↲
↲
╞ ┆a1┆Message format┆e1┆ :↲
╞ ╞ message sent answer received↲
╞ ╞ u1╞ 12╞ ╞ unch↲
╞ ╞ u2╞ 7╞ result↲
╞ ╞ u3╞ -╞ ╞ unch↲
╞ ╞ u4╞ -╞ ╞ unch↲
↲
╞ ╞ buf╞ -╞ ╞ unch↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆If the dte_lcnzero process wants to stop timer t20 this message is ↓
┆19┆┆89┆┄┄sent to the timer process. The answer is always expected to have ↓
┆19┆┆89┆┄┄the result 'ok'.↲
↲
╞ ┆a1┆Result┆e1┆:↲
╞ ok (0) : message processed properly↲
↲
↲
┆a1┆3.2.5╞ Process dte_chan↲
↲
╞ ┆84┆The following internal/external messages are handled by the ↓
┆19┆┆89┆┄┄dte_chan process.↲
↲
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╞ name╞ sending╞ receiving╞ section↲
╞ ╞ process╞ process↲
↲
╞ restart_start dte╞ ╞ dte_chan╞ 3.2.5.1↲
╞ sync_mess dte╞ ╞ dte_chan╞ 3.2.5.1↲
↲
╞ timer_book dte_chan╞ timeout╞ 3.2.5.2↲
╞ timer_update dte_chan╞ timeout╞ 3.2.5.2↲
↲
╞ x25_input╞ dte_hrec╞ dte_chan╞ 3.5.2.1↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
════════════════════════════════════════════════════════════════════════
↓
┆84┆╞ ┆84┆Besides these messages the dte_chan process receives the following ↓
┆19┆┆89┆┄┄DTE User messages↲
↲
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╞ ╞ - dte_call_req↲
╞ ╞ - dte_change_mode↲
╞ ╞ - dte_clear_req↲
╞ ╞ - dte_rec_dedic↲
╞ ╞ - dte_reset_req↲
╞ ╞ - dte_send_data↲
╞ ╞ - dte_send_intrupt↲
╞ ╞ - dte_sync_stream↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
↲
┆a1┆3.2.5.1╞ Messages received↲
↲
┆b0┆╞ ┆a1┆Message name┆e1┆ : restart_start↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ message╞ answer↲
╞ ╞ u1 252╞ unch↲
╞ ╞ u2 15╞ result↲
╞ ╞ u3 -╞ unch↲
╞ ╞ u4╞ 8╞ unch↲
↲
╞ ╞ buf╞ -╞ unch↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The DCE/DTE interface has entered a restart phase. All user mes┄↓
┆19┆┆89┆┄┄sages are returned with result 'not_processed' (9) and all timers ↓
┆19┆┆89┆┄┄stopped. The dte_chan process then enters the stopping phase util┄↓
┆19┆┆89┆┄┄izing the ┆b0┆sync_mess┆f0┆ to synchronize with the dte process, before it ↓
┆19┆┆89┆┆81┆┄is removed.↲
↲
╞ ┆a1┆Result┆e1┆:↲
╞ ok (0) : message processed properly↲
╞ not_processed (9) : message received in stopping phase↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ┆a1┆Message name┆e1┆ : sync_mess↲
↲
╞ ┆a1┆Message format┆e1┆ :↲
╞ ╞ message╞ answer↲
╞ ╞ u1 0╞ unch↲
╞ ╞ u2╞ 7╞ result↲
╞ ╞ u3╞ -╞ cause↲
╞ ╞ u4 11╞ unch↲
↲
╞ ╞ buf sync_buf_type╞ unch↲
↲
╞ ╞ sync_buf_type = record↲
╞ ╞ ╞ ch_index : integer;↲
╞ ╞ ╞ lcn_index╞ : byte;↲
╞ ╞ ╞ lcg╞ : bit4;↲
╞ ╞ ╞ lcn╞ : byte;↲
╞ ╞ ╞ user_no╞ : byte;↲
╞ ╞ ╞ local_uaddr╞ : local_adr_type;↲
╞ ╞ ╞ default_w,↲
╞ ╞ ╞ max_w╞ : bit3;↲
╞ ╞ ╞ rr-timer,↲
╞ ╞ ╞ ack_timer╞ : integer;↲
╞ ╞ ╞ end;↲
↲
╞ ╞ local_adr_type = record↲
╞ ╞ ╞ user_lgth╞ : byte;↲
╞ ╞ ╞ user_address : bcd_adr_type;↲
╞ ╞ ╞ end,↲
↲
╞ ╞ bcd_adr_type = packed array (1..max_u_adr) of bit4;↲
↲
╞ ╞ max_u_adr = 5;↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆This message is received at the sync semaphore. When received in ↓
┆19┆┆89┆┄┄the state xidle the buffer contains different parameter values to ↓
┆19┆┆89┆┄┄be used for the actual incarnation of an X.25 logical channel. The ↓
┆19┆┆89┆┄┄parameters are:↲
════════════════════════════════════════════════════════════════════════
↓
╞ ch_index╞ : index to chan_proc_table, used by dte↲
╞ lcn_index╞ : index to lcn_table, used by dte↲
╞ lcg╞ : logical group number, used by dte and dte_chan↲
╞ lcn╞ : logical channel number, used by dte and dte_chan↲
╞ user_no╞ : actual user number, used by dte_chan↲
╞ local_uaddr : local user address, used by dte_chan↲
╞ default_w : default X.25 window size, used by dte_chan↲
╞ max_w : max window size allowed, used by dte_chan↲
╞ rr_timer╞ : idle timer value, used by dte_chan↲
╞ ack_timer╞ : acknowledge timer value, used by dte_chan↲
↲
╞ ┆84┆Furthermore, the message is used to synchronize the dte and ↓
┆19┆┆89┆┄┄dte_chan process in the stopping phase of the last one (see ↓
┆19┆┆89┆┄┄subsection 4.2.7).↲
↲
╞ ┆84┆The cause field identifies the parts of the stoppng phase:↲
╞ ╞ cause = 3 : stopping phase initiated↲
╞ ╞ ╞ = 0 : stopping phase ended↲
↲
╞ ┆a1┆Result┆e1┆:↲
╞ ok╞ (0) : message processed properly↲
↲
╞ ┆a1┆┆e1┆┆a1┆┆b0┆Message name┆e1┆ : x25_input↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ received answer↲
╞ ╞ u1 ╞ 1↲
╞ ╞ u2╞ 0↲
╞ ╞ u3╞ -↲
╞ ╞ u4╞ 6↲
↲
╞ ╞ buf x25_buf_type↲
↲
╞ ╞ x25_buf_type = record↲
╞ ╞ ╞ first,last,next : integer;↲
╞ ╞ ╞ head : x25_head;↲
╞ data ╞ : ┆84┆array (first+3..last) ↓
┆19┆┆b6┆┄┄of byte;↲
╞ ╞ ╞ end;↲
════════════════════════════════════════════════════════════════════════
↓
╞ ╞ x25_head = packed record↲
╞ ╞ ╞ q_bit,↲
╞ ╞ ╞ d_bit,↲
╞ ╞ ╞ m128,↲
╞ ╞ ╞ m8 : bit; ↲
╞ ╞ ╞ lcgn : bit4;↲
╞ ╞ ╞ lcn : byte;↲
╞ ╞ ╞ packet_id : byte;↲
╞ ╞ ╞ end;↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The buffer is received from the dte_hrec process. It contains a ↓
┆19┆┆89┆┄┄received X.25 packet on the X.25 logical channel handled by this ↓
┆19┆┆89┆┄┄dte_chan process incarnation. The packet type is identified and ↓
┆19┆┆89┆┄┄depending of this and the internal state a specified action is ↓
┆19┆┆89┆┄┄per┄formed.↲
↲
↲
┆a1┆3.2.5.2╞ Messages sent↲
↲
╞ ┆84┆The next two messages concerns the communication with the timeout ↓
┆19┆┆89┆┄┄process. The messages are sent by calling one of the two external ↓
┆19┆┆89┆┄┄procedures: timerbook, timerupdate. For a more detailed descrip┄↓
┆19┆┆89┆┄┄tion than given below, please refer to ref. (6).↲
↲
╞ ┆a1┆┆b0┆Message name┆e1┆ : timer_book↲
↲
╞ ┆a1┆Message format┆e1┆ : ↲
╞ ╞ top message╞ ╞ stacked message↲
╞ ╞ message answer╞ message answer↲
╞ ╞ u1 7╞ unch╞ 5 unch↲
╞ ╞ u2 7 result - result↲
╞ ╞ u3 - unch - unch↲
╞ ╞ u4 5 unch╞ - unch↲
↲
╞ ╞ buf - timers╞ updates unch↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ╞ timers = record↲
╞ ╞ ╞ obj : integer;↲
╞ ╞ ╞ end;↲
↲
╞ ╞ updates = record↲
╞ ╞ ╞ index,↲
╞ ╞ ╞ count,↲
╞ ╞ ╞ obj : integer;↲
╞ ╞ ╞ end;↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The dte_chan process requests a timer entry and start of the re┄↓
┆19┆┆89┆┄┄quested timer. If ok the stacked message is returned with result ↓
┆19┆┆89┆┄┄'result_ok' (1). After the time period specified in count (number ↓
┆19┆┆89┆┄┄of ticks) the top message is returned with result 'result_ok' (1).↲
↲
╞ ┆84┆The parameter obj is used to identify the timer in the ↓
┆19┆┆89┆┄┄dte_chan/timeout communication.↲
↲
╞ ┆84┆Index is set by timeout at booking time and is used later on at ↓
┆19┆┆89┆┄┄each new update of the timer as a reference number by the timeout ↓
┆19┆┆89┆┄┄process.↲
↲
╞ ┆a1┆Result┆e1┆:↲
╞ result_ok (1) : message processed properly↲
╞ result_full (2) : no timer entry available↲
↲
┆b0┆╞ ┆a1┆Message name┆e1┆ : timer_update↲
↲
╞ ┆a1┆Message format┆e1┆ :↲
╞ ╞ message╞ answer↲
╞ ╞ u1 4╞ unch↲
╞ ╞ u2 7╞ result↲
╞ ╞ u3 -╞ unch↲
╞ ╞ u4 -╞ unch↲
↲
╞ ╞ buf updates╞ unch↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ╞ updates = record↲
╞ ╞ ╞ index,↲
╞ ╞ ╞ count,↲
╞ ╞ ╞ obj : integer;↲
╞ ╞ ╞ end;↲
↲
╞ ┆a1┆Function┆e1┆:↲
╞ ┆84┆The dte_chan process requests the timeout process to update an ↓
┆19┆┆89┆┄┄already started timer. If count = 0 the dte_chan process stops the ↓
┆19┆┆89┆┄┄timer by requesting it returned immediately. For specification of ↓
┆19┆┆89┆┄┄index and obj, please refer to ┆b0┆timer_book┆f0┆.↲
↲
╞ ┆a1┆Result┆e1┆:↲
╞ result_ok (1) : message processed properly↲
╞ result_wrong (3) : no timer message pending↲
╞ result_obj (4) : wrong obj used↲
╞ result_index (5) : index out of range↲
↲
↲
┆a1┆3.2.6╞ Process dte_pool.↲
↲
╞ ┆84┆As already mentioned (in chapter 2) the dte_pool process is an in┄↓
┆19┆┆89┆┄┄carnation of the pool_handler process. So for a detailed descrip┄↓
┆19┆┆89┆┄┄tion of messages please refer to ref. (5).↲
↲
════════════════════════════════════════════════════════════════════════
↓
«index» formatlinie til RC manualer↲
┆14┆┆b3┆↲
┆14┆┆b3┆┆06┆- ┆0b┆ -↲
┆a1┆↓
┆a1┆4.╞ PROCESS DESCRIPTIONS.↲
↲
╞ ┆84┆Section 4.1 gives some general information which is common to a ↓
┆19┆┆89┆┄┄number of DTE processes, whereas the following sections (4.2-4.6) ↓
┆19┆┆89┆┄┄describe the processes one by one.↲
↲
╞ ┆84┆The actual process descriptions cover the following aspects.↲
↲
┆b0┆╞ - process parameters┆f0┆ (subsection 4.x.1)↲
╞ ┆84┆The process head is shown and the parameters are described. ↓
┆19┆┆8d┆┄┄Please note that frozen VAR parameters (!) are read-only ↓
┆19┆┆8d┆┄┄parameters.↲
↲
╞ ┆b0┆- states┆f0┆ (subsection 4.x.2)↲
╞ ┆84┆A description is given of the possible values of state ↓
┆19┆┆8d┆┄┄variables in the process. This description can include a state ↓
┆19┆┆8d┆┄┄transition graph or table.↲
↲
┆b0┆╞ - semaphores and reference variables┆f0┆ (subsection 4.x.3)↲
╞ ┆84┆The local semaphores (excl. process parameters) and the ↓
┆19┆┆8d┆┄┄reference variables are described.↲
↲
╞ ┆b0┆- data structures┆f0┆ (subsection 4.x.4)↲
╞ ┆84┆A description of important data structures is given.↲
↲
┆b0┆╞ - semaphores and message flow┆f0┆ (subsection 4.x.5)↲
╞ ┆84┆An outline of the flow of messages to and from the process is ↓
┆19┆┆8e┆┄┄shown. The use of the main semaphore and additional semapho-↓
┆19┆┆8e┆┄┄res (incl. buffer pools) is illustrated.↲
↲
┆b0┆╞ - overview of process operation┆f0┆ (subsection 4.x.6)↲
╞ ┆84┆A short description of the internal structure and work of the ↓
┆19┆┆8e┆┄┄process is given.↲
↲
┆b0┆╞ - special techniques┆f0┆ (subsection 4.x.7 and on)↲
┆84┆If any special implementation techniques or methods are used ↓
┆19┆┆8d┆┄┄these are described.↲
↲
╞ ┆84┆Please refer to chapter 2 for an overall description of the ↓
┆19┆┆89┆┄┄processes.↲
↲
↲
┆8c┆┄┆ab┆↓
┆a1┆4.1╞ General Information.↲
↲
↲
┆a1┆4.1.1╞ Common Data Structures.↲
↲
↲
┆a1┆4.1.1.1╞ User Table.↲
↲
╞ ┆84┆Each user connected to the DTE is described by an entry in the ↓
┆19┆┆89┆┄┄user_table. Two processes operate on this table, dte and ↓
┆19┆┆89┆┄┄dte_access. One operation on the table is to find a given user and ↓
┆19┆┆89┆┄┄for this purpose the procedure ┆b0┆found_user┆f0┆ (subsection 4.1.2.3) is ↓
┆19┆┆89┆┆81┆┄defined. An access semaphore (user_key) is associated with the ↓
┆19┆┆89┆┆81┆┄table. The process which at a given moment 'owns' the message ╞ ↓
┆19┆┆89┆┆81┆┄(key) queued at the semaphore, has the rights to read and write ↓
┆19┆┆89┆┆81┆┄in the table.↲
↲
╞ ┆84┆Each entry in the table is of type↲
↲
╞ user_desc = record↲
╞ user_state╞ : u_state_type;↲
╞ local_uaddr╞ : bcd_adr_type;↲
accept_range,↲
╞ user_streams,↲
╞ lost_stream_event,↲
╞ lost_user_event╞ : byte;↲
╞ user_event_rec╞ : dte_event_type;↲
╞ general_bsem,↲
w_event_bsem╞ : semaphore;↲
╞ end;↲
↲
╞ user_state╞ : ┆84┆Describes the state (free, w_resc, idle, ↓
┆19┆┆9f┆┄┄active) of the entry/associated user. Please ↓
┆19┆┆9f┆┄┄refer to subsection 4.3.2 for a description ↓
┆19┆┆9f┆┄┄of the individual states.↲
↲
╞ local_uaddr╞ : ┆84┆Contains the user address (X.25 sub ad┄↓
┆19┆┆9f┆┄┄dress). See subsection 4.1.6.↲
↲
╞ accept_range╞ : ┆84┆See subsection 4.1.6.↲
↲
┆8c┆┄┆a9┆↓
╞ user_streams╞ : ┆84┆The number of streams for this user.↲
↲
╞ lost_stream_event╞ : ┆84┆Number of streams with lost events.↲
↲
╞ lost_user_event╞ : ┆84┆Number of lost user events.↲
↲
╞ user_event_rec╞ : ┆84┆Last received user event containing event ↓
┆19┆┆9f┆┄┄type, cause and diagnostic.↲
↲
╞ general_bsem╞ : ┆84┆Semaphore at which general input buffers are ↓
┆19┆┆9f┆┄┄queued.↲
↲
╞ w_event_bsem╞ : ┆84┆Semaphore at which wait_event buffers are ↓
┆19┆┆9f┆┄┄queued.↲
↲
↲
┆a1┆4.1.1.2╞ Semaphore Area for dte_chan<xxx>.↲
↲
╞ ┆84┆In the dte process two tables, containing semaphore pointers to ↓
┆19┆┆89┆┄┄the main semaphores of the dte_chan incarnations, are defined. ↓
┆19┆┆89┆┄┄These two tables (hrec_table and int_table) are process parameters ↓
┆19┆┆89┆┄┄to the dte_hrec and dte_access process, respectively. In these ↓
┆19┆┆89┆┄┄processes they are used to route messages to the right dte_chan ↓
┆19┆┆89┆┄┄incarnation.↲
↲
╞ ┆84┆In dte_hrec the index to the table is calculated from the logical ↓
┆19┆┆89┆┄┄channel number (see subsection 4.1.5). If the associated dte_chan ↓
┆19┆┆89┆┄┄incarnation is in state xidle the semaphore pointer points to the ↓
┆19┆┆89┆┄┄main semaphore of the dte process. This dynamical change is per┄↓
┆19┆┆89┆┄┄formed by the dte process. A snap shot is given below in figure 9.↲
↲
╞ ┆84┆In dte_access the stream number is used as index to stream_table, ↓
┆19┆┆89┆┄┄which contains a semaphore pointer (chanproc_sem) to the associa┄↓
┆19┆┆89┆┄┄ted dte_chan incarnation. This pointer is assigned to the value of ↓
┆19┆┆89┆┄┄int_table(index) at stream initialization. Index is returned by ↓
┆19┆┆89┆┄┄the dte process in a chan_start answer. A snap shot is given below ↓
┆19┆┆89┆┄┄in figure 9.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
┆06┆Figure 9. Snap shot of routing pointers.↲
↲
↲
┆a1┆┆81┆↓
┆a1┆4.1.1.3╞ x25_param_type.↲
↲
╞ ┆84┆A call and return parameters to the X.25 procedures ┆b0┆code_x25┆f0┆ (sub┄↓
┆19┆┆89┆┆81┆┄section 4.1.2.1) and ┆b0┆dce_x25┆f0┆ (subsection 4.1.2.1) is of type ↓
┆19┆┆89┆┆82┆┄x25_param_type. This parameter contains all the necessary parame┄↓
┆19┆┆89┆┆82┆┄ters to code or decode an X.25 packet.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ x25_param_type = record↲
╞ xlcg : bit4;↲
xlcn : byte;↲
╞ xpacket_id╞ : packet_id_type;↲
╞ qbit,↲
╞ dbit,↲
╞ mbit╞ : bit;↲
╞ spr,↲
╞ sps,↲
╞ rpr,↲
╞ rps╞ : bit3;↲
╞ octet4,↲
╞ octet5╞ : byte;↲
╞ end;↲
↲
╞ xlcg╞ ╞ : ┆84┆Logical group number in the X.25 packet ↓
┆19┆┆9f┆┄┄header.↲
↲
╞ xlcn╞ ╞ : ┆84┆Logical channel number in the X.25 packet ↓
┆19┆┆9f┆┄┄header.↲
↲
╞ xpacket_id╞ : ┆84┆Packet identificator.↲
↲
╞ qbit,dbit,mbit╞ : q, d and m bit in the X.25 packet header.↲
↲
╞ spr, sps╞ ╞ : ┆84┆PR and PS numbers to be written in the X.25 ↓
┆19┆┆9f┆┄┄packet head, that has to be transmitted to ↓
┆19┆┆9f┆┄┄the DCE.↲
↲
╞ rpr, rps╞ ╞ : ┆84┆PR and PS numbers read in the X.25 packet ↓
┆19┆┆9f┆┄┄head received from the DCE.↲
↲
╞ octet4╞ ╞ : Octet four in some X.25 packets.↲
↲
╞ octet5╞ ╞ : Octet five in some X.25 packets.↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.1.1.4╞ Zones.↲
↲
╞ ┆84┆In the processes dte, dte_lcnzero a standard zone (outzone) is ↓
┆19┆┆89┆┄┄used to write error messages and other information on the console. ↓
┆19┆┆89┆┄┄For definition and use of the zone please refer to ref. (15).↲
↲
↲
┆a1┆4.1.2╞ Common or General Procedures.↲
↲
↲
┆a1┆4.1.2.1╞ X.25 Procedures.↲
↲
╞ ┆84┆In order easely to operate on X.25 packets from different processes ↓
┆19┆┆89┆┄┄7 procedures are defined:↲
↲
╞ - code_x25↲
╞ - dec_x25↲
╞ - init_x25faci↲
╞ - check_x25faci↲
╞ - check_facispec↲
╞ - init_window↲
╞ - w_algorithm↲
↲
╞ ┆84┆code_x25 and dec_x25 is used to code and decode an X.25 header ↓
┆19┆┆89┆┄┄and sometimes octet 4 and 5 in the packets. They have the formats↲
↲
┆b0┆╞ PROCEDURE code_x25 (↲
╞ VAR msg╞ : reference;↲
╞ pfirst╞ : integer;↲
╞ dte╞ : boolean;↲
╞ VAR x25_param : x25_param_type↲
╞ packet_lgth : integer↲
╞ );↲
↲
┆b0┆╞ FUNCTION dec_x25 (↲
╞ VAR msg╞ : reference;↲
╞ pfirst : integer;↲
╞ dte╞ : boolean;↲
╞ VAR x25_param : x25_param_type↲
╞ VAR packet_lgth : integer↲
╞ ) : packet_result;↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ - ┆84┆msg is a reference to either the buffer in which the packet has ↓
┆19┆┆8b┆┄┄to be coded in or the buffer in which the packet is received in.↲
╞ - ┆84┆pfirst is a pointer to the first byte of the packet.↲
- ┆84┆dte specifies whether the function has to be DTE (true) or DCE ↓
┆19┆┆8b┆┄┄(false).↲
╞ - x25_param is described in subsection 4.1.1.3.↲
╞ ┆84┆- packet_lgth is the packet length including the head.↲
↲
╞ ┆84┆┆b0┆code_x25┆f0┆ makes up the packet according to the parameters, special ↓
┆19┆┆89┆┆81┆┄x25_param.xpacket_id, and ┆b0┆dec_x25┆f0┆ returns the fields in the para┄↓
┆19┆┆89┆┆82┆┄meters and the result in packet_result (see appendix B.3).↲
↲
╞ ┆84┆To handle the X.25 facilities three procedures are defined:↲
↲
┆b0┆╞ FUNCTION init_x25faci (↲
╞ VAR x25_ref╞ : reference;↲
╞ VAR faci_start,↲
╞ faci_last,↲
╞ index╞ : integer;↲
╞ VAR standard,↲
more : boolean↲
) : boolean;↲
↲
┆b0┆╞ FUNCTION check_x25faci (↲
╞ VAR x25_ref : reference;↲
faci_start,↲
faci_last : integer;↲
VAR index : integer;↲
VAR standard,↲
more : boolean;↲
VAR faci_size : byte;↲
VAR facilities : array (1..4) of byte↲
) : faci_result_type;↲
↲
┆b0┆FUNCTION check_facispec (↲
facility,↲
default_faci,↲
spec_faci : byte↲
) : boolean;↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆┆b0┆init_x25faci┆f0┆ is used to initialize the variables faci_start, ↓
┆19┆┆89┆┆81┆┄faci_last, index, standard and more.↲
- ┆84┆index points to the next facility↲
- ┆84┆standard is true if the last returned facility was an standard ↓
┆19┆┆8b┆┄┄X.25 facility.↲
- ┆84┆more is true if there is more facilities.↲
↲
┆84┆At return from ┆b0┆check_x25faci┆f0┆ the variables are updated and fa┄↓
┆19┆┆89┆┆81┆┄cilities contains the just read facility, faci_size the number of ↓
┆19┆┆89┆┆81┆┄octets defined for the facilit┄y and the result is specified as the ↓
┆19┆┆89┆┆81┆┄result of the function.↲
↲
╞ ┆b0┆┆84┆check_facispec┆f0┆ is used to check that the negotiation of a facility ↓
┆19┆┆89┆┆81┆┄is towards the default value (default_faci). The parameter facili┄↓
┆19┆┆89┆┆81┆┄ty is the new value and spec_faci the current value.↲
↲
╞ ┆84┆To support the X.25 window mechanism two procedures are defined:↲
↲
┆b0┆╞ PROCEDURE init_window (↲
VAR window_rec : window_rec_desc;↲
╞ queue_use,↲
reset_only : boolean↲
);↲
↲
┆b0┆╞ FUNCTION w_algorithm (↲
packet_type : packet_id_type;↲
mode : transmode_type;↲
VAR p_r,↲
p_s : bit3;↲
VAR window_rec : window_rec_type;↲
VAR return_buf : byte↲
) : boolean;↲
↲
╞ ┆84┆┆b0┆init_window┆f0┆ is call to initialize the variables in window_rec, ↓
┆19┆┆89┆┆81┆┄containing lower window edge for receiving/sending, next P(S) to ↓
┆19┆┆89┆┆81┆┄sent, last received P(S) and number of input buffers. The ↓
┆19┆┆89┆┆81┆┄procedure is called when the call set-up or reset phase is ended.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆┆b0┆w_algorithm┆f0┆ is call every time an RR, RNR or DATA packet is either ↓
┆19┆┆89┆┆81┆┄received or has to be sent (specified with mode). The variables in ↓
┆19┆┆89┆┆81┆┄window_rec is updated and return_buf specifies (at receival) the ↓
┆19┆┆89┆┆81┆┄number of acknowledged packets. The variables p_r and p_s either ↓
┆19┆┆89┆┆81┆┄are the values to be written in the packet (call values) or val┄↓
┆19┆┆89┆┆81┆┄ues read in the packet (return values). If the function return with ↓
┆19┆┆89┆┆81┆┄true the values were ok and the packet can either be sent or is ↓
┆19┆┆89┆┆81┆┄received ok.↲
↲
↲
┆a1┆4.1.2.2╞ Modem Signals Handling.↲
↲
╞ ┆84┆In order to handle the modem signals two external procedures are ↓
┆19┆┆89┆┄┄defined:↲
↲
┆b0┆╞ FUNCTION clear_modem (↲
VAR reset_ref : reference;↲
VAR hdlc_semp,↲
hardwait : ! sempointer;↲
VAR modem_signal : byte↲
) : boolean;↲
↲
┆b0┆╞ FUNCTION set_modem (↲
VAR reset_ref : reference;↲
VAR hdlc_semp,↲
hardwait : ! sempointer;↲
VAR modem_signal : byte;↲
test_modem : boolean;↲
version : byte;↲
) : boolean;↲
↲
╞ ┆84┆Both procedures operate on the variable modem_signal, which has to ↓
┆19┆┆89┆┄┄be interpreted as a bit string:↲
↲
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╞ ╞ _________________________↲
╞ ╞ ┆a1┆ ! ! ! ! ! ! ! ↲
╞ ╞ ╞ ╞ ╞ DCD↲
╞ ╞ ╞ ╞ ╞ DSR↲
╞ ╞ ╞ ╞ ╞ SQD↲
╞ ╞ ╞ ╞ ╞ RI↲
╞ ╞ ╞ ╞ ╞ RTS↲
╞ ╞ ╞ ╞ ╞ DTR↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
┆8c┆┄┆ab┆↓
╞ ┆84┆The procedure ┆b0┆clear_modem┆f0┆ clears the two signals DTR and RTS.↲
↲
╞ ┆84┆The procedure ┆b0┆set_modem┆f0┆ first sets the signal DTR, then waits ↓
┆19┆┆89┆┆81┆┄(maximum 1 sec) on DSR setting, then sets the signal RTS and at ↓
┆19┆┆89┆┆81┆┄last waits (maximum 2 secs) on DCD setting before returning. These ↓
┆19┆┆89┆┆81┆┄two waits can be suspended by calling the procedure with ↓
┆19┆┆89┆┆81┆┄test_modem equal to false.↲
↲
╞ ┆84┆reset_ref holds a message used to the hdlc operations, hdlc_semp ↓
┆19┆┆89┆┄┄is the semaphore pointer to the HDLCLCP and hardwait to the answer ↓
┆19┆┆89┆┄┄semaphore of the message.↲
↲
↲
┆a1┆4.1.2.3╞ User Table Operations.↲
↲
╞ ┆84┆In order to find a specified user in the user_table one procedure ↓
┆19┆┆89┆┄┄is defined:↲
┆b0┆╞ FUNCTION found_user (↲
╞ opcode : byte;↲
bcd_nos : bcd_adr_type;↲
VAR user_no : byte;↲
VAR user_table : u_table_type↲
) : boolean;↲
↲
╞ ┆84┆The function is called in order to find a specified user ↓
┆19┆┆89┆┄┄(bcd_nos). If the request is to find a user for an INCOMING CALL ↓
┆19┆┆89┆┄┄(opcode = inc_call), then the result is successful depending on ↓
┆19┆┆89┆┄┄the particular matching (please refer to section 4.1.6) of the ↓
┆19┆┆89┆┄┄sub_address contained in the called dte address.↲
↲
╞ opcode╞ ╞ : ┆84┆Either inc_call (X.25 INCOMING CALL) or ↓
┆19┆┆9f┆┄┄dte_disc_user (user disconnect message).↲
↲
╞ bcd_nos ╞ : User identification.↲
↲
╞ user_no╞ : ┆84┆At return the index to the user_table, if ↓
┆19┆┆9f┆┄┄user is found.↲
↲
╞ user_table╞ : Pointer to actual user_table.↲
↲
↲
┆8c┆┄┆a9┆↓
┆a1┆4.1.2.4╞ Error Text Procedures.↲
↲
╞ ┆84┆To support error message writing, two procedures are defined, ┆b0┆er┄↓
┆19┆┆89┆┆81┆┆82┆ror_text┆f0┆ and ┆b0┆error_report┆f0┆. ┆b0┆error_text┆f0┆ operates on an output zone ↓
┆19┆┆89┆┆83┆┄to write the error message in text form, whereas ┆b0┆error_report┆f0┆ uses ↓
┆19┆┆89┆┆84┆┄the procedure trace to write a single integer and maybe the u-↓
┆19┆┆89┆┆84┆┄fields of a message.↲
↲
┆b0┆╞ PROCEDURE error_text (↲
╞ VAR out : zone;↲
fatal : boolean;↲
basic,↲
no : byte;↲
digit : integer;↲
name : alfa;↲
text : array (1..80) of char;↲
text length,↲
process_vers : byte↲
);↲
↲
╞ ┆84┆If basic = 0, no specifies the error text↲
↲
╞ no = 0╞ : link error↲
╞ = 1 : create error↲
= 2 : pool increase error↲
= 3 : pool init error↲
↲
╞ and name contains either a process or pool name.↲
↲
╞ ┆84┆If basic >0 different output types are defined.↲
Text is written follow by↲
↲
╞ basic = 1 : the byte value of digit↲
= 2 : the integer value of digit↲
= 3 : name↲
= 4 : nothing.↲
↲
╞ ┆84┆If fatal is true the procedure ends by calling ┆b0┆panic┆f0┆ with the pro┄↓
┆19┆┆89┆┆81┆┄cess_vers as parameter. process_vers is a process version number.↲
↲
┆8c┆┄┆a8┆↓
┆b0┆╞ PROCEDURE error_report (↲
proc_id,↲
error_inf : byte;↲
mess,↲
stop : boolean;↲
VAR mess_ref : reference↲
);↲
↲
╞ ┆84┆The procedure calls ┆b0┆trace┆f0┆ with the parameter 'proc_id * 256 + ↓
┆19┆┆89┆┆81┆┄error_inf'. If mess is true, the u-fields of the message hanging ↓
┆19┆┆89┆┆81┆┄on mess_ref is printed too. If stop is true the procedure ends by ↓
┆19┆┆89┆┆81┆┄calling ┆b0┆panic┆f0┆ with the value 1.↲
↲
╞ ┆84┆The different error messages are described in chapter 5.↲
↲
↲
┆a1┆4.1.2.5╞ Tracing Procedures.↲
↲
╞ ┆84┆For tracing purpose three procedures are defined, ┆b0┆init_trace, ↓
┆19┆┆89┆┆81┆┆82┆end_trace┆f0┆ and ┆b0┆tracing.↲
↲
╞ ┆84┆All three procedures request a buffer from the pool trace_buf ↓
┆19┆┆89┆┄┄(subsection 4.1.3), set the trace fields and return it to the ↓
┆19┆┆89┆┄┄dtetrace process (section 6.1).↲
↲
╞ ┆84┆┆b0┆init_trace┆f0┆ generates a message, which provoke the dtetrace pro┄cess ↓
┆19┆┆89┆┆81┆┄to write the date, time and 'trace start' on the console and ↓
┆19┆┆89┆┆81┆┄┆b0┆end_trace┆f0┆ the date, time and 'trace stopped'. The procedure ┆b0┆trac┄↓
┆19┆┆89┆┆83┆┆82┆ing┆f0┆ copies the X.25 packet to a trace buffer.↲
↲
┆b0┆╞ PROCEDURE init_trace (↲
VAR trace_rec : trace_type;↲
VAR trace_buf : ph_type↲
);↲
↲
┆b0┆╞ PROCEDURE end_trace (↲
VAR trace_rec : trace_type;↲
VAR trace_buf : ph_type↲
);↲
↲
┆8c┆┄┆a8┆↓
┆b0┆╞ PROCEDURE tracing (↲
VAR dref : reference;↲
mode : trace_tmode;↲
VAR trace_rec : trace_type;↲
VAR trace_buf : ph_type↲
);↲
↲
╞ trace_rec : ┆84┆Variable containing a buffer request message ↓
┆19┆┆9f┆┄┄and the answer semaphore.↲
↲
╞ trace_buf : Trace buffer pool.↲
↲
╞ dref : ┆84┆Holds the message containing the X.25 ↓
┆19┆┆9f┆┄┄packet.↲
↲
╞ mode : ┆84┆Specifies either send (xmit) or receive ↓
┆19┆┆9f┆┄┄(recv).↲
↲
╞ ┆84┆All three procedures wait on an empty buffer if no one is pres┄↓
┆19┆┆89┆┄┄ent.↲
↲
↲
┆a1┆4.1.2.6╞ Internal Test Procedures.↲
↲
╞ ┆84┆In each process performing internal test a procedure of the fol┄↓
┆19┆┆89┆┄┄lowing form is defined.↲
↲
┆b0┆╞ PROCEDURE otest (↲
╞ oper : 0..15;↲
╞ (* maybe parameters *)↲
╞ );↲
↲
╞ ┆84┆This procedure produces the actual test records. Whenever the in┄↓
┆19┆┆89┆┄┄ternal test area is full a test buffer is requested from the test ↓
┆19┆┆89┆┄┄pool (testsem) and if ok the procedure ┆b0┆copy_test┆f0┆ is called to copy ↓
┆19┆┆89┆┆81┆┄the test area to the buffer and reset the pointers. For a detailed ↓
┆19┆┆89┆┆81┆┄description please refer to section 6.2.↲
↲
↲
┆8c┆┄┆a7┆↓
┆a1┆4.1.3╞ Buffer Pools.↲
↲
╞ ┆84┆As already mentioned the DTE uses the pool_handler system (ref. ↓
┆19┆┆89┆┄┄(5)) to support pool handling.↲
↲
╞ A buffer pool is defined by the type:↲
↲
╞ ph_type = record↲
╞ key : semaphore;↲
buffer_sem : semaphore;↲
bpool : bst;↲
prio : prtable;↲
end;↲
↲
╞ key : Access semaphore to the buffer pool.↲
↲
╞ buffer_sem : Buffers are queued at this semaphore.↲
↲
╞ bpool : General statistic counters.↲
↲
╞ prio : ┆84┆Contains for every priority (0..3) a ↓
┆19┆┆a4┆┄┄wait request semaphore and statistic ↓
┆19┆┆a4┆┄┄counters.↲
↲
╞ ┆84┆The DTE module uses four buffer pools of this type:↲
↲
╞ bigbuf : ┆84┆Big input buffers for X.25 packets. Signalled to ↓
┆19┆┆9a┆┄┄the HDLCLCP as input buffers and on return routed ↓
┆19┆┆9a┆┄┄to an internal process (dte, dte_lcnzero or ↓
┆19┆┆9a┆┄┄dte_chanxxx) by the dte_hrec process. From these ↓
┆19┆┆9a┆┄┄processes they are returned to the pool.↲
↲
╞ smallbuf : ┆84┆Small input buffers. Used to copy a small X.25 ↓
┆19┆┆9a┆┄┄packet (┆a1┆<┆e1┆ 5 bytes) into and signal this buffer to ↓
┆19┆┆9a┆┄┄an internal process (dte, dte_lcnzero or ↓
┆19┆┆9a┆┄┄dte_chanxxx) by the dte_hrec process. From these ↓
┆19┆┆9a┆┄┄processes they are returned to the pool.↲
════════════════════════════════════════════════════════════════════════
↓
╞ x25buf : ┆84┆X.25 output control buffers. The processes dte, ↓
┆19┆┆9a┆┄┄dte_lcnzero and dte_chanxxx request these buf┄fers ↓
┆19┆┆9a┆┄┄for X.25 packets less than or equal to 5 bytes, ↓
┆19┆┆9a┆┄┄signal the message to the HDLCLCP for trans┄↓
┆19┆┆9a┆┄┄mission to the DCE. They are returned to the ↓
┆19┆┆9a┆┄┄dte_pool process, which return them to the pool.↲
↲
╞ trace_buf : ┆84┆Trace buffer pool. Please refer to section 6.1.↲
↲
╞ ┆84┆In figure 10 the flow of the buffers are shown.↲
↲
╞ bigbuf:↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ smallbuf:↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
┆8c┆┄┆a7┆↓
╞ x25buf:↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 10: Buffer flow for bigbuf, smallbuf and x25buf.↲
↲
╞ ┆84┆For management of these buffer pools (incl. NC operations) the DTE ↓
┆19┆┆89┆┄┄uses the following procedures:↲
↲
┆b0┆╞ PROCEDURE request_buffer ┆f0┆(VAR ref : reference;↲
╞ VAR ph : ph_type; priority : 0..3;↲
VAR result : reference);↲
↲
┆b0┆╞ PROCEDURE return_buffer ┆f0┆(VAR ref : reference;↲
VAR ph : ph_type; VAR help_ref : reference);↲
↲
┆b0┆╞ PROCEDURE remove_buffers ┆f0┆(VAR ph : ph_type;↲
╞ count : integer);↲
↲
┆b0┆╞ PROCEDURE deliver_buffer ┆f0┆(VAR ref : reference;↲
╞ VAR ph : ph_type);↲
↲
┆b0┆╞ PROCEDURE reset_ph_stat ┆f0┆(VAR ph : ph_type);↲
↲
┆b0┆╞ PROCEDURE init_ph ┆f0┆(VAR ph : ph_type;↲
╞ VAR lockpool : pool 1);↲
↲
┆8c┆┄┆a7┆↓
╞ ┆84┆For a detailed description please refer to ref. (5).↲
↲
↲
┆a1┆4.1.4╞ Timers in the DTE Module.↲
↲
╞ ┆84┆Several timers are used in the DTE module. Some of these concern ↓
┆19┆┆89┆┄┄internal events and communication with other processes in the TC. ↓
┆19┆┆89┆┄┄The rest concern communication with the DCE. These last timers are ↓
┆19┆┆89┆┄┄described by↲
↲
╞ timer_desc = record↲
╞ ticks : integer;↲
╞ state : timer_state;↲
timer_event_no : integer;↲
end;↲
↲
╞ ticks : ┆84┆Defines the number of ticks, if the ↓
┆19┆┆a4┆┄┄TIMEOUT module is used as timer ↓
┆19┆┆a4┆┄┄process.↲
↲
╞ state : ┆84┆Defines the state of the timer (see ↓
┆19┆┆a4┆┄┄below).↲
↲
╞ timer_event_no : Event number for state_machine action.↲
↲
╞ A timer may be in one of three states↲
↲
╞ t_stop╞ : The timer is not active.↲
↲
╞ t_run : The timer is active.↲
↲
╞ t_update : ┆84┆At the time where an update was required, the ti┄↓
┆19┆┆9a┆┄┄mer message was not returned. When the timer mes┄↓
┆19┆┆9a┆┄┄sage is received, the timer is started again.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆The names of the above mentioned timers are:↲
↲
╞ t11m╞ : DCE call request timer.↲
t12m : DCE reset request timr.↲
t20 : DTE restart request timer.↲
t21 : DTE call request timer.↲
t22 : DTE reset request timer.↲
t23 : DTE clear request timer.↲
t30 : Virtual Call idle timer.↲
t31 : Data hold timer.↲
↲
╞ ┆84┆The value for each timer in the DTE module is specified in the ↓
┆19┆┆89┆┄┄array timer_def (DTEENV, appendix B.5).↲
↲
↲
┆a1┆4.1.5╞ Relation between Streams and Logical Channels.↲
↲
╞ ┆84┆Each connected user has its own ┆a1┆streams┆e1┆ (data pathes), identified ↓
┆19┆┆89┆┄┄by numbers, in the dte_access process. All streams for all users ↓
┆19┆┆89┆┄┄have individual numbers, so a data path is always identified by ↓
┆19┆┆89┆┄┄one number (stream number) in the DTE/User interface. The ↓
┆19┆┆89┆┄┄dte_access process handles the connection between an ┆b0┆X.25 Virtual ↓
┆19┆┆89┆┆81┆┆82┆Call ┆f0┆and the ┆b0┆stream.↲
↲
╞ ┆84┆The Virtual Call has a logical channel number at the DTE/DCE in┄↓
┆19┆┆89┆┄┄terface, and all Virtual Calls are multiplexed on one hdlc line to ↓
┆19┆┆89┆┄┄the DCE (figure 11).↲
↲
╞ ┆84┆The stream number is always assigned by the dte_access process, ↓
┆19┆┆89┆┄┄and the data path to the remote user is identified by this number, ↓
┆19┆┆89┆┄┄when it has been set up. The user needs not care about the logical ↓
┆19┆┆89┆┄┄channel numbers, they are only significant for the DTE module.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 11. Relation between streams and logical channels.↲
↲
↲
┆a1┆4.1.6╞ Addresses used by the DTE.↲
↲
╞ The DTE utilizes two types of addresses:↲
↲
╞ - user identification↲
╞ - DTE address↲
↲
╞ ┆84┆The user identification is used to separate the connected users in ↓
┆19┆┆89┆┄┄order to make it possible for the DTE to route an INCOMING CALL to ↓
┆19┆┆89┆┄┄the right user. Furthermore it is used as part (sub address) of ↓
┆19┆┆89┆┄┄the DTE address.↲
↲
╞ ┆84┆The DTE address is the identification of the DTE and user in the ↓
┆19┆┆89┆┄┄total network. The DTE module applies no constraints on the format ↓
┆19┆┆89┆┄┄of the addresses, but it is recommended to follow CCITT recommen┄↓
┆19┆┆89┆┄┄dation X.121 (ref. (2)). Below is given an example of a DTE ↓
┆19┆┆89┆┄┄address.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆The types and constants defining the addresses and length of these ↓
┆19┆┆89┆┄┄are:↲
↲
╞ dte_addr_lgt = 14 : ┆84┆Maximum DTE address length.↲
┆b0┆Cannot be changed.↲
↲
╞ max_u_adr = 5 : ┆84┆Maximum length of user identification. ↓
┆19┆┆a4┆┄┄┆b0┆Cannot be changed.↲
↲
╞ net_adr_length = 13 : ┆84┆Actual length of network address.↲
┆b0┆May be changed at compilation.↲
↲
╞ user_id_lgth = 3 : ┆84┆Actual length of user identification. ↓
┆19┆┆a4┆┄┄┆b0┆May be changed at compilation.↲
↲
╞ actual_u_lgt =↲
╞ dte_addr_lgt - net_adr_length: actual length of sub address.↲
↲
╞ x25_adr_type = array (1.. dte_addr_lgt) of byte;↲
↲
╞ bcd_adr_type = array (1.. max_u_adr) of bit4;↲
↲
╞ adr_rec_type = record↲
╞ extended_format : boolean;↲
╞ adr_lgth : byte;↲
╞ adr : x25_adr_type;↲
╞ end;↲
↲
╞ local_adr_type = record↲
╞ user_lgth : byte;↲
╞ user_address : bcd_adr_type;↲
╞ end;↲
↲
╞ ┆84┆The environments, in which the individual types and constants are ↓
┆19┆┆89┆┄┄defined, is outlined in table 3 below.↲
↲
╞ ┆84┆adr_rec_type is used to define variables containing own DTE ↓
┆19┆┆89┆┄┄address or remote DTE address.↲
↲
┆8c┆┄┆a7┆↓
╞ ┆84┆local_adr_type is used to define variables containing converted ↓
┆19┆┆89┆┄┄(from ASCII string to binary digits) user identification.↲
↲
╞ _________________________________________________________________ ↲
╞ ! type/constant ! changable ! defined in ! appendix !↲
╞ ┆a1┆! name ! ! environment ! !↲
╞ ! ! ! ! !↲
╞ ! dte_addr_lgt ! no ! netenv ! - !↲
╞ ! max_u_adr ! no ! cnnetenv ! - !↲
╞ ! net_adr_length ! yes ! cnnetenv ! - !↲
╞ ! user_id_lgth ! yes ! xdteenv ! B.2 !↲
╞ ! actual_u_lgt ! implicit ! cnnetenv ! - !↲
╞ ! x25_adr_type ! - ! cnnetenv ! - !↲
╞ ! bcd_adr_type ! - ! cnnetenv ! - !↲
╞ ! adr_rec_type ! - ! cnnetenv ! - !↲
╞ ! local_adr_type ! - ! cnnetenv ! - !↲
╞ ┆a1┆! ! ! ! !↲
↲
↲
╞ Table 3: ┆84┆Environments in which address types and constants are ↓
┆19┆┆92┆┄┄defined.↲
↲
↲
┆b0┆ ┆a1┆Example 1:↲
↲
╞ country code↲
╞ national number↲
↲
↲
╞ _____________________________↲
╞ ┆a1┆ 2 3 8 1 0 4 0 1 0 1 2 0 1 1 ↲
╞ ╞ ╞ ╞ data network number↲
↲
╞ ╞ ╞ ╞ sub address↲
network address↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.1.6.1╞ User Identification.↲
↲
╞ ┆84┆At connect time the user identifies itself by a numeric text ↓
┆19┆┆89┆┄┄string. The length of this text string may vary from 1 to ↓
┆19┆┆89┆┄┄max_u_adr digits. The actual length is specified by user_id_lgth ↓
┆19┆┆89┆┄┄and is a compilation parameter of the DTE module.↲
↲
╞ ┆84┆The dte_access process converts this identification to binary dig┄↓
┆19┆┆89┆┄┄its before using it as sub address in the Virtual Call establish┄↓
┆19┆┆89┆┄┄ment phase.↲
↲
╞ ┆84┆Furthermore the user may at connect time specify how many digits, ↓
┆19┆┆89┆┄┄the DTE shall use in the routing algorithm of an INCOMING CALL.↲
↲
╞ ┆84┆The field sub_id_lgt (accept_range internal in the DTE) in the ↓
┆19┆┆89┆┄┄service primitive connect_user specifies the number of leading di┄↓
┆19┆┆89┆┄┄gits of the converted user identification to be used in filtering ↓
┆19┆┆89┆┄┄an INCOMING CALL:↲
↲
╞ sub_id_lgt = 0↲
╞ all calls are accepted↲
╞ sub_id_lgt = 1↲
╞ ┆84┆only calls, where the first digit of the subaddress matches ↓
┆19┆┆8f┆┄┄with the first digit of the user identification, are accept┄↓
┆19┆┆8f┆┄┄ed↲
╞ sub_id_lgt = 2↲
╞ only calls, where two digits match, are accepted↲
╞ sub_id_lgt = 3↲
╞ only calls, where three digits match, are accepted↲
╞ sub_id_lgt > 3↲
╞ no calls are accepted↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.1.6.2╞ DTE Address.↲
↲
╞ ┆84┆The DTE address is the address of the receiver/sender of a CALL ↓
┆19┆┆89┆┄┄REQUEST packet, and consists of two parts (see above), a network ↓
┆19┆┆89┆┄┄address and a sub address. The maximum length of a DTE address is ↓
┆19┆┆89┆┄┄14 digits (dte_addr_lgt).↲
↲
╞ ┆84┆The network address identifies a DTE module/physical unit among ↓
┆19┆┆89┆┄┄all DTE modules in the network.↲
↲
╞ ┆84┆The own network address and the length of it (own_dte_adr), toget┄↓
┆19┆┆89┆┄┄her with the actual sub address length (dte_conf_rec.user_length) ↓
┆19┆┆89┆┄┄are process parameters to the dte process. At initialization the ↓
┆19┆┆89┆┄┄dte process checks these three parameters:↲
↲
╞ ╞ user_length <= max_u_adr↲
╞ ╞ adr_lgth <= dte_addr_lgt↲
╞ ╞ user_length + adr_lgth <= dte_addr_lgt↲
╞ ╞ adr(I) are all digits↲
↲
╞ ┆84┆A user_length and adr_lgth of zero is allowed. If adr_lgth is zero ↓
┆19┆┆89┆┄┄user_length should also be set to zero.↲
↲
╞ ┆84┆The concatenation of the network address and the subaddress may ↓
┆19┆┆89┆┄┄not always fit the DTE address in length. The DTE handles this ↓
┆19┆┆89┆┄┄problem according to the following four rules:↲
↲
╞ Given:╞ DTE address length╞ ╞ = 14↲
╞ ╞ network address length ╞ = x↲
╞ ╞ user identification length╞ = y↲
╞ ╞ sub address length╞ ╞ = 14-x↲
↲
╞ ┆a1┆Rule 1┆e1┆:↲
╞ ┆84┆If ┆b0┆sending a CALL REQUEST packet ┆f0┆and ┆b0┆(14-x) < y ┆f0┆the user iden┄↓
┆19┆┆8c┆┆82┆┄tification is truncated to fit the subaddress length.↲
↲
╞ ┆a1┆Rule 2┆e1┆:↲
╞ ┆84┆If ┆b0┆sending a CALL REQUEST packet ┆f0┆and ┆b0┆(14-x) > y ┆f0┆the DTE address ↓
┆19┆┆8c┆┆82┆┄if filled with binary zero's after the subaddress.↲
↲
┆8c┆┄┆a8┆↓
╞ ┆a1┆Rule 3┆e1┆:↲
╞ ┆84┆If ┆b0┆receiving an INCOMING CALL packet ┆f0┆and ┆b0┆(14-x) < y ┆f0┆the receiv┄↓
┆19┆┆8c┆┆82┆┄ed user identification is filled with binary zero's, before the ↓
┆19┆┆8c┆┆82┆┄routing/searching algorithm is invoked.↲
↲
╞ ┆a1┆Rule 4┆e1┆:↲
╞ ┆84┆If ┆b0┆receiving an INCOMING CALL packet ┆f0┆and ┆b0┆(14-x) > y ┆f0┆the re┄↓
┆19┆┆8c┆┆82┆┄ceived user identification is truncated, before the rou┄↓
┆19┆┆8c┆┆82┆┄ting/sear┄ch┄ing algorithm is invoked.↲
↲
↲
╞ The next two examples show the rules impact on the addresses.↲
↲
┆b0┆╞ ┆a1┆Example 2:↲
╞ Given:╞ user_id_length╞ = 3↲
╞ ╞ user_id╞ ╞ = '123'↲
╞ ╞ network_addr_length = 13↲
╞ ╞ own_network_addr╞ = 2381040101201↲
╞ ╞ called_dte_address = 23810401012011↲
↲
╞ This will give:↲
↲
╞ Calling dte address in CALL REQUEST packet (rule 1):↲
╞ ╞ ┆a1┆23810401012011↲
↲
╞ ┆84┆User identification subtracted from called_dte_address in an INCO┄↓
┆19┆┆89┆┄┄MING CALL packet and used in the routing/searching algorithm (rule ↓
┆19┆┆89┆┄┄3):↲
╞ ╞ ┆a1┆1↲
↲
┆b0┆╞ ┆a1┆Example 3:↲
╞ Given:╞ user_id_length╞ = 3↲
╞ ╞ user_id╞ ╞ = '123'↲
╞ ╞ network_addr_length╞ = 10↲
╞ ╞ own_network_addr╞ = 2381040201↲
╞ ╞ called_dte_address╞ = 23810402011234↲
════════════════════════════════════════════════════════════════════════
↓
╞ This will give:↲
↲
╞ Calling dte address in CALL REQUEST packet (rule 2):↲
╞ ╞ ┆a1┆23810402011230↲
↲
╞ ┆84┆User identification subtracted from called_dte_address in an INCO┄↓
┆19┆┆89┆┄┄MING CALL packet and used in the routing/searching algorithm (rule ↓
┆19┆┆89┆┄┄4):↲
╞ ╞ ┆a1┆1234↲
↲
↲
┆a1┆4.1.6.3╞ Address Procedures.↲
↲
╞ ┆84┆In order to be able to perform the above described concatenation/ ↓
┆19┆┆89┆┄┄separation and packing/unpacking of DTE address to/from X.25 pack┄↓
┆19┆┆89┆┄┄ets two procedures are defined:↲
↲
┆b0┆╞ PROCEDURE pack_adr (↲
╞ pkt_type╞ : packet_id_type;↲
╞ VAR user_ref,↲
╞ ╞ x25_ref : reference;↲
╞ VAR ufaci_start,↲
╞ xfaci_start : integer;↲
╞ head_index : integer;↲
VAR local_user : local_adr_type;↲
╞ VAR own,↲
╞ ╞ remote : adr_rec_type;↲
╞ VAR result : byte↲
);↲
↲
╞ pkt_type╞ : ┆84┆Specifies whether it is a CALL REQUEST or ↓
┆19┆┆9f┆┄┄CALL ACCEPT packet.↲
↲
╞ user_ref╞ : ┆84┆Holds the user dte_call_req message.↲
↲
╞ x25_ref╞ : Holds the buffer containing the X.25 packet.↲
↲
╞ ufaci_start╞ : ┆84┆Points at return to the facilities in the ↓
┆19┆┆9f┆┄┄user dte_call_req.↲
↲
┆8c┆┄┆a8┆↓
╞ xfaci_start╞ : ┆84┆Points at return to the first byte for ↓
┆19┆┆9f┆┄┄facilities in the X.25 packet.↲
↲
╞ head_index╞ : ┆84┆Points at call to the first data byte in the ↓
┆19┆┆9f┆┄┄user dte_call_req.↲
↲
╞ local_user╞ : ┆84┆Defines the calling local user (sub add┄↓
┆19┆┆9f┆┄┄ress).↲
↲
╞ own╞ ╞ : Defines the calling network address.↲
↲
╞ remote╞ ╞ : Contains at return the called DTE address.↲
↲
╞ result╞ ╞ : ┆84┆If different from ok (0) there were problems ↓
┆19┆┆9f┆┄┄in packing the addresses.↲
↲
↲
┆b0┆╞ PROCEDURE unpack_adr (↲
╞ VAR user_ref,↲
╞ ╞ x25_ref╞ : reference;↲
╞ VAR ufaci_start↲
╞ ╞ xfaci_start : integer;↲
╞ head_index : integer;↲
╞ VAR local_user : local_adr_type;↲
╞ VAR own,↲
╞ ╞ remote : adr_rec_type↲
);↲
↲
╞ user_ref╞ : ┆84┆Holds the 'user' buffer for an INCOMING ↓
┆19┆┆9f┆┄┄CALL.↲
↲
╞ x25_ref╞ : ┆84┆Holds the message containing the X.25 ↓
┆19┆┆9f┆┄┄INCOMING CALL packet.↲
↲
╞ ufaci_start╞ : ┆84┆Points at return to the first byte for ↓
┆19┆┆9f┆┄┄facilities in the 'user' buffer.↲
↲
╞ xfaci_start╞ : ┆84┆Points at return to the first byte of ↓
┆19┆┆9f┆┄┄facilities in the X.25 packet.↲
↲
┆8c┆┄┆a8┆↓
╞ head_index╞ : ┆84┆Points at call to the first data byte in ↓
┆19┆┆9f┆┄┄the 'user' buffer.↲
↲
╞ local_user╞ : ┆84┆Contains at return the called local user ↓
┆19┆┆9f┆┄┄(sub address).↲
↲
╞ own╞ ╞ : ┆84┆Only network address length (adr_lgth) is ↓
┆19┆┆9f┆┄┄used.↲
↲
╞ remote╞ ╞ : ┆84┆Contains at return the calling DTE address.↲
↲
╞ ┆84┆In appendix G are the transfer from user dte_call_req to the X.25 ↓
┆19┆┆89┆┄┄CALL REQUEST packet, from X.25 INCOMING CALL packet to user mes┄↓
┆19┆┆89┆┄┄sage shown.↲
↲
↲
┆a1┆4.1.7 Naming of Running Process Incarnations.↲
↲
╞ ┆84┆The dte process uses its own name as a prefix for the names of the ↓
┆19┆┆89┆┄┄children incarnations. Some general conventions for the names have ↓
┆19┆┆89┆┄┄been defined :↲
↲
╞ 1. ┆84┆The dte uses up to four characters (first four) of its own ↓
┆19┆┆8e┆┄┄name (own.incarname) as prefix.↲
↲
╞ 2. ┆84┆Process of the trace, test and snoop systems will have no '_' ↓
┆19┆┆8e┆┄┄between the prefix and the name.↲
↲
╞ ┆84┆This gives the following names of the process incarnations :↲
↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a142328323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
╞ ╞ dte╞ : defined by father process↲
╞ ╞ dte_access╞ : <prefix>_access↲
╞ ╞ dte_chan╞ : <prefix>_chan<seq. no>↲
╞ ╞ dte_hrec╞ : <prefix>_hrec↲
╞ ╞ dte_lcnzero╞ : <prefix>_lcnzero↲
╞ ╞ pool_handler╞ : <prefix>_pool↲
╞ ╞ dtetest╞ : <prefix>test↲
╞ ╞ dteclock╞ : <prefix>clock↲
┆8c┆┄┆a7┆↓
╞ ╞ dtetrace╞ : <prefix>trace↲
╞ ╞ outtrace╞ : <prefix>outtrace↲
╞ ╞ snoop╞ : <prefix>snoop↲
↲
↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a142328323c464b555f69737d8791ff04╱
↓
╞ ┆84┆The procedure ┆b0┆c_name┆f0┆ is used to generate the names :↲
↲
╞ ┆b0┆FUNCTION c_name (↲
╞ prefixx,↲
╞ suffixx : alfa;↲
╞ func,↲
╞ incar_no : byte↲
╞ ) : alfa;↲
↲
╞ prefixx : Name of calling process.↲
╞ suffixx : Characters to be added.↲
╞ func : Defines the function to be performed.↲
╞ incar_no : ┆84┆A sequence number added as the last three ↓
┆19┆┆98┆┄┄characters if func specifies this.↲
════════════════════════════════════════════════════════════════════════
↓
«index» formatlinie til RC manualer↲
┆14┆┆b3┆↲
┆14┆┆b3┆┆06┆- ┆0b┆ -↲
┆a1┆4.2╞ Description of dte.↲
↲
╞ ┆84┆The dte (supervisor) process is the parent process of the DTE ↓
┆19┆┆89┆┄┄Module/System as already described in chapter 2.↲
╞ The main purpose is:↲
↲
╞ 1) ┆84┆creating the other DTE processes and dynamical creating/┄↓
┆19┆┆8c┆┄┄removing the dte_chan process incarnations↲
↲
╞ 2) ┆84┆creation and removal of the DTE Trace and Test Systems↲
↲
╞ 3) ┆84┆checking runtime configuration of the DTE↲
↲
╞ 4) handling of LCP events and operations↲
↲
╞ 5) ┆84┆handling events from the HDLCLCP and connecting/disconnecting ↓
┆19┆┆8c┆┄┄the hdlc line↲
↲
╞ 6) ┆84┆management of the user table in connection with the dte_access ↓
┆19┆┆8c┆┄┄process↲
↲
╞ 7) ┆84┆making the connection between INCOMING CALL's or user ↓
┆19┆┆8c┆┄┄dte_call_req's, and the local channel process (dte_chanxxx)↲
↲
╞ 8) ┆84┆handling the assigned logical channel numbers and set up the ↓
┆19┆┆8c┆┄┄connection between a logical channel number and a user stream ↓
┆19┆┆8c┆┄┄number.↲
↲
↲
┆a1┆4.2.1╞ Process Parameters.↲
↲
╞ PROCESS dte (↲
╞ VAR sysvector : system_vector;↲
╞ VAR dte_ptr,↲
╞ ╞ sup_ptr,↲
╞ ╞ lcn0_ptr,↲
╞ ╞ hrec_ptr,↲
╞ ╞ pool_ptr,↲
╞ ╞ hardwait : ! tap_pointer;↲
┆8c┆┄┆a7┆↓
╞ VAR hdlc_semp,↲
╞ ╞ timeout_semp,↲
╞ ╞ ncp_semp : ! sempointer;↲
╞ VAR locksem : semaphore;↲
╞ dte_lcp_id : lcp_ident_type;↲
╞ hdlc_param : hdlc_cp_type;↲
╞ dte_conf_rec : dte_cp_type;↲
╞ own_dte_adr : adr_rec_type;↲
╞ pool_conf_rec╞ : dte_pc_type;↲
╞ debug_rec : dte_dc_type↲
╞ );↲
↲
╞ sysvector : The system semaphores.↲
↲
╞ dte_ptr : Main semaphore pointer of the DTE module.↲
↲
╞ sup_ptr : dte local main semaphore pointer.↲
↲
╞ lcn0_ptr : dte_lcnzero main semaphore pointer.↲
↲
╞ hrec_ptr : dte_hrec main semaphore pointer.↲
↲
╞ pool_ptr : dte_pool main semaphore pointer.↲
↲
╞ hardwait : Local hardwait semaphore pointer.↲
↲
╞ hdlc_semp : ┆84┆┆84┆Main semaphore pointer of the HDLCLCP module.↲
↲
╞ timeout_semp : ┆84┆Main semaphore pointer of the TIMEOUT module.↲
↲
╞ ncp_semp : ┆84┆Main semaphore pointer of the NCP module.↲
↲
╞ locksem : Console access semaphore.↲
↲
╞ dte_lcp_id : lcp_id (lcp address) of the DTE module.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ hdlc_param : hdlc connect parameters↲
╞ ╞ hdlc_cp_type = record↲
╞ ╞ test_modem, (* true if modem *)↲
╞ ╞ ╞ ╞ (* signals shall *)↲
╞ ╞ ╞ ╞ (* be tested *)↲
╞ ╞ ╞ com204 : boolean; (* true if HDLC *)↲
╞ ╞ ╞ (* is COM204 *)↲
╞ ╞ ╞ c_id,╞ (* see ref (9) *)↲
╞ ╞ ╞ t1, (* - " - *)↲
╞ ╞ ╞ n2 : integer; (* - " - *)↲
╞ ╞ ╞ k : byte; (* - " - *)↲
╞ ╞ framespace, (* - " - *)↲
╞ ╞ ╞ abortspace: integer; (* - " - *)↲
╞ ╞ end;╞ ↓
↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d87ffff04╱
↓
↲
╞ dte_conf_rec : Run time configuration of the DTE module↲
╞ ╞ dte_cp_type = record↲
x25_lcg :bit4 (* logical group number *)↲
╞ ╞ dltc, (* default lowest two- *)↲
╞ ╞ ╞ (* way channel number *)↲
╞ ╞ dhtc :integer;(* default highest two- *)↲
╞ ╞ ╞ ╞ (* way channel number *)↲
╞ ╞ max_chan, (* maximum X.25 channels*)↲
dw_size, (* default window size *)↲
╞ ╞ maxw_size, (* max window size *)↲
╞ user_length :byte; (* actual user id *)↲
(* length *)↲
x25_datasize :integer;(* X.25 data packet *)↲
(* size *)↲
end;↲
↲
╞ own_dte_adr : The X.25 address of this DTE (see subsection 4.1.6)↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ pool_conf_rec: Configuration of internal pools↲
dte_pc_type = record↲
suphead_no, (* no. of internal *)↲
(* headers *)↲
supmess_no, (* no. of internal *)↲
(* supervisor buffers*)↲
eventbuf_no, (* no. of internal *)↲
(* event buffers *)↲
hdlc_eventno: integer; (* no. of hdlc *)↲
(* event buffers *)↲
end;↲
↲
╞ debug_rec : Debug parameters↲
dte_dc_type = record↲
dtetest, (* true if back to *)↲
(* back test *)↲
snoop_on, (* true if internal *)↲
(* message snoop *)↲
def_trace: boolean; (* true if X.25 *)↲
(* level 3 trace *)↲
def_test : testrectype;(* test bits *)↲
(* see section 6.2 *)↲
end;↲
↲
↲
┆a1┆4.2.2╞ States.↲
↲
┆84┆The dte process maintains a state variable, dte_state, which ref┄↓
┆19┆┆89┆┄┄lects the state of the whole DTE module. It also maintains a sta┄te ↓
┆19┆┆89┆┄┄variable, line_state, which reflects the DTE's view of the hdlc ↓
┆19┆┆89┆┄┄line (see also subsection 4.2.8).↲
↲
╞ ┆b0┆dte_state:↲
↲
╞ ┆b0┆ dte_ready ┆84┆┆f0┆the DTE is in ready state, i.e. r1 according to ↓
┆19┆┆9a┆┆81┆┄the X.25 Recommendation (ref. (1))↲
↲
╞ ┆b0┆dte_restart ┆84┆┆f0┆the DTE is in a restart phase, i.e. r2 according ↓
┆19┆┆9a┆┆81┆┄to the X.25 Recommendation (ref. (1))↲
↲
┆8c┆┄┆a8┆↓
╞ ┆b0┆hdlc_active ┆84┆┆f0┆the hdlc line is connected, but level 3 has not ↓
┆19┆┆9a┆┆81┆┄yet exchanged RESTART packets↲
↲
╞ ┆b0┆net_down ┆84┆┆f0┆the hdlc line is disconnected↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 12: State transition graph for dte_state in process dte.↲
↲
↲
┆b0┆╞ line_state:↲
↲
╞ ┆b0┆h_conn ┆f0┆the hdlc line is connected↲
↲
╞ ┆b0┆h_conn_ing ┆84┆┆f0┆the hdlc line is being connected, i.e.↲
┆84┆a connect message has been sent, but an event (0) ↓
┆19┆┆9a┆┄┄has not yet been received↲
↲
╞ ┆b0┆h_disc_ing ┆84┆┆f0┆the hdlc line is being disconnected, i.e.↲
┆84┆an event (7,8,9 or 10) has been received, but an ↓
┆19┆┆9a┆┄┄event (3) has not yet been received↲
↲
╞ ┆b0┆h_recv_disc ┆84┆┆f0┆the hdlc line has been disconnected by the other ↓
┆19┆┆9a┆┆81┆┄end, i.e. an event (4) has been received and ↓
┆19┆┆9a┆┆81┆┄state was h_conn_ing↲
↲
╞ ┆b0┆h_disc ┆84┆┆f0┆the hdlc line is disconnected.↲
↲
┆8c┆┄┆a8┆↓
╞ ┆84┆A state transition graph and table for line state is outlined in ↓
┆19┆┆89┆┄┄subsection 4.2.8.↲
↲
↲
┆a1┆4.2.3╞ Semaphore and Reference Variables.↲
↲
╞ ┆84┆Variables of type 'sempointer' and 'tap_pointer' are mentioned in ↓
┆19┆┆89┆┄┄the semaphore subsection just as they were semaphores.↲
↲
╞ ┆a1┆┆b0┆SEMAPHORES↲
↲
╞ breaksem╞ ╞ : ┆84┆A semaphore used to hold a break message. ↓
┆19┆┆9f┆┄┄This message is used by other DTE processes ↓
┆19┆┆9f┆┄┄to report exceptions to the dte process.↲
↲
╞ ev_pool_sem╞ : ┆84┆Used as a DTE global event pool. Each pro┄↓
┆19┆┆9f┆┄┄cess (except dte) picks up an event buffer ↓
┆19┆┆9f┆┄┄from this semaphore, puts data in the buf┄↓
┆19┆┆9f┆┄┄fer, and returns it to the dte process.↲
↲
╞ local_insem╞ : ┆84┆Local input semaphore used in connection ↓
┆19┆┆9f┆┄┄with restart_sem and sync_sem to seperate ↓
┆19┆┆9f┆┄┄the input stream into channel synchroniza┄↓
┆19┆┆9f┆┄┄tion messages (sync_sem), restart messages ↓
┆19┆┆9f┆┄┄(restart_sem), and all others (local_insem).↲
↲
╞ own_ev_sem╞ : ┆84┆Used as a local event buffer pool, only ↓
┆19┆┆9f┆┄┄known by the dte process. The reason for ha┄↓
┆19┆┆9f┆┄┄ving two internal event pools is to avoid ↓
┆19┆┆9f┆┄┄the deadlock:↲
╞ ╞ ╞ ┆84┆the dte process waits a buffer at ↓
┆19┆┆9f┆┄┄ev_pool_sem, but all the event buffers are ↓
┆19┆┆9f┆┄┄queued at its main input semaphore.↲
↲
╞ poolh_ncpsem╞ : ┆84┆Dummy semaphore used as NCP main semaphore ↓
┆19┆┆9f┆┄┄in the dte_pool process.↲
↲
╞ restart_sem╞ : ┆84┆Local input semaphore, used for restart mes┄↓
┆19┆┆9f┆┄┄sages (see local_insem).↲
↲
┆8c┆┄┆a8┆↓
╞ sync_sem╞ ╞ : ┆84┆Local input semaphore used for channel syn┄↓
┆19┆┆9f┆┄┄chronization messages (see local_insem).↲
↲
╞ user_key╞ ╞ : ┆84┆Access semaphore (holds a buffer used as a ↓
┆19┆┆9f┆┄┄key) to the user table.↲
↲
╞ int_hdlc_ptr╞ : ┆84┆A sempointer which points at HDLCLCP if X.25 ↓
┆19┆┆9f┆┄┄trace is off and at the outtrace process if ↓
┆19┆┆9f┆┄┄X.25 trace is on.↲
↲
╞ chan_table(n).╞ : A sempointer pointing at the general_bsem↲
╞ general_bsem ┆84┆semaphore in the user_table. This is the ↓
┆19┆┆9f┆┄┄connection from a dte_chan process incarna┄↓
┆19┆┆9f┆┄┄tion to the general input semaphore of the ↓
┆19┆┆9f┆┄┄user, who at the moment is associated with ↓
┆19┆┆9f┆┄┄this dte_chan process incarnation (see sub┄↓
┆19┆┆9f┆┄┄section 4.2.7).↲
↲
╞ chan_table(n).in_ptr: ┆84┆Main 'semaphore' for a dte_chan process in┄↓
┆19┆┆9f┆┄┄carnation (see subsection 4.2.7).↲
↲
╞ chan_table(n). : ┆84┆Synchronization 'semaphore' for a dte_chan↲
╞ sync_ptr process incarnation (see subsection 4.2.7).↲
↲
╞ hrec_table╞ : ┆84┆Array of pointers to the input semaphores of ↓
┆19┆┆9f┆┄┄the dte_chan process incarnations. A process ↓
┆19┆┆9f┆┄┄parameter to the dte_hrec process (see sub┄↓
┆19┆┆9f┆┄┄sections 4.1.1.2 and 4.2.7).↲
↲
╞ int_table╞ ╞ : ┆84┆Array of pointers to the input semaphores of ↓
┆19┆┆9f┆┄┄the dte_chan process incarnations. A process ↓
┆19┆┆9f┆┄┄parameter to the dte_access process (see ↓
┆19┆┆9f┆┄┄subsec┄tion 4.1.1.2 and 4.2.7).↲
↲
╞ trace_sem and ╞ : Main input semaphore of the dtetrace pro-↲
╞ trace_ptr ┆84┆cess (trace_ptr(1)) and outtrace process ↓
┆19┆┆9f┆┄┄(trace_ptr(2)).↲
↲
╞ trace_rec.wsem╞ : ┆84┆Answer semaphore used in the tracing proce┄↓
┆19┆┆9f┆┄┄dures (see subsection 4.1.2.5).↲
↲
┆8c┆┄┆a9┆↓
╞ snoop_ptr╞ ╞ : ┆84┆Array of tap_pointers used by the snoop ↓
┆19┆┆9f┆┄┄process (see ref (7)).↲
↲
╞ dte_test_sem╞ : ┆84┆Main input semaphore of the dtetest process.↲
↲
╞ testsem╞ ╞ : ┆84┆Semaphore used as a DTE global test buffer ↓
┆19┆┆9f┆┄┄pool.↲
↲
↲
┆b0┆╞ ┆a1┆REFERENCES↲
↲
╞ clock_ref╞ ╞ : Holds a ┆b0┆get_clock┆f0┆ message.↲
↲
╞ header_ref╞ : Working reference.↲
↲
╞ key_ref╞ ╞ : ┆84┆Used to hold the key message during access ↓
┆19┆┆9f┆┄┄to pools and the user table.↲
↲
╞ mess_ref╞ ╞ : Holds the message under processing.↲
↲
╞ ncp_ref╞ ╞ : ┆84┆Holds an NC-restart request while awaiting ↓
┆19┆┆9f┆┄┄restart confirmation from the dte_lcnzero ↓
┆19┆┆9f┆┄┄process.↲
↲
╞ ctrl_ref╞ ╞ : ┆84┆Holds a buffer used to disconnect the hdlc ↓
┆19┆┆9f┆┄┄line or to modem signals setting.↲
↲
╞ req_ref╞ ╞ : ┆84┆Working reference.↲
↲
╞ timer_ref╞ ╞ : ┆84┆Holds a buffer used for a short delay in ↓
┆19┆┆9f┆┄┄case of problem at modem signal setting.↲
↲
╞ trace_rec.t_ref╞ : ┆84┆┆84┆Working reference used in the tracing proce┄↓
┆19┆┆9f┆┄┄dures (see subsection 4.1.2.5).↲
↲
╞ testref╞ ╞ : ┆84┆Working reference used during copying the ↓
┆19┆┆9f┆┄┄internal test area to a test buffer.↲
↲
↲
┆8c┆┄┆a7┆↓
┆a1┆4.2.4╞ Data Structures.↲
↲
╞ ┆84┆The following data structures used in the dte process are describ┄↓
┆19┆┆89┆┄┄ed elsewhere.↲
↲
╞ x25_param╞ section 4.1.1.3↲
╞ user_table╞ section 4.1.1.1↲
╞ hrec_table╞ section 4.1.1.2↲
╞ int_table╞ section 4.1.1.2↲
╞ test╞ ╞ section 6.2.1↲
╞ testbuf╞ section 6.2.4.1↲
↲
╞ ┆84┆The dte process also uses a zone (z) for printing of error ↓
┆19┆┆89┆┄┄messages and other information on the console.↲
↲
╞ ┆84┆Besides these the below described data structures are important ↓
┆19┆┆89┆┄┄for understanding the internal structure and work of the dte ↓
┆19┆┆89┆┄┄process.↲
↲
╞ dte_param_rec,↲
╞ new_dte_param╞ : ┆84┆Both of type dte_rec_type defined in the ↓
┆19┆┆9f┆┄┄DTEENV (appendix B.5). They both contain in┄↓
┆19┆┆9f┆┄┄formation about lowest and highest assign ↓
┆19┆┆9f┆┄┄twoway logical channel number, number of in┄↓
┆19┆┆9f┆┄┄put buffers at the HDLC driver, and values ↓
┆19┆┆9f┆┄┄for the two timers t30 (idle timer) and t32 ↓
┆19┆┆9f┆┄┄(ack timer). dte_param_rec contains the ac┄↓
┆19┆┆9f┆┄┄tual values and new_dte_param the possible ↓
┆19┆┆9f┆┄┄new values. The change from one set to anot┄↓
┆19┆┆9f┆┄┄her (updating of seperate values or all) may ↓
┆19┆┆9f┆┄┄be initiated by the LCP operation ↓
┆19┆┆9f┆┄┄restart_dte (DTE 54,0).↲
↲
╞ chan_vector╞ : ┆84┆Array of pairs of semaphores used as input ↓
┆19┆┆9f┆┄┄semaphores for the dte_chan process incarna┄↓
┆19┆┆9f┆┄┄tions. See also chan_table(n).in_prt below.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ sync_vector╞ : ┆84┆Array of pairs of semaphores used as syn┄↓
┆19┆┆9f┆┄┄chronization semaphores for the dte_chan ↓
┆19┆┆9f┆┄┄process incarnations.↲
┆84┆See also chan_table(n).sync_ptr below.↲
↲
╞ lcn_table╞ ╞ : ┆84┆Array of type lcn_entry.↲
╞ ╞ ╞ lcn_entry = record↲
╞ ╞ ╞ state : lcn_state_type;↲
╞ ╞ ╞ index_pct : integer;↲
end;↲
╞ ╞ ╞ ┆84┆Used in creation/removal of dte_chan process ↓
┆19┆┆9f┆┄┄incarnations (subsection 4.2.7).↲
↲
╞ chan_table╞ : ┆84┆Array of dte_chan descriptors. Each entry is ↓
┆19┆┆9f┆┄┄of type chan_desc.↲
↲
╞ chan_desc = record↲
╞ ╞ lcg╞ : bit4;↲
╞ ╞ lcn╞ : byte;↲
╞ ╞ proc_state╞ : proc_state_type;↲
╞ ╞ in_ptr╞ : tap_pointer;↲
╞ ╞ sync_ptr╞ : tap_pointer;↲
╞ ╞ general_bsem╞ : sempointer;↲
╞ ╞ incar_state╞ : incar_state_type;↲
╞ ╞ chan_sh╞ : shadow;↲
╞ ╞ end;↲
↲
╞ lcg, lcn╞ : ┆84┆Defines the logical group and channel ↓
┆19┆┆9f┆┄┄number.↲
↲
╞ proc_state╞ : ┆84┆dte_chan process state (see subsection ↓
┆19┆┆9f┆┄┄4.2.7).↲
↲
╞ in_ptr╞ ╞ : dte_chan incarnation main semaphore pointer.↲
↲
╞ sync_ptr╞ : ┆84┆dte_chan incarnation synchronization sema┄↓
┆19┆┆9f┆┄┄phore pointer.↲
↲
╞ general_bsem╞ : General input semaphore pointer.↲
↲
┆8c┆┄┆a8┆↓
╞ incar_state╞ : ┆84┆State (iremoved, inot_removed) of the incar┄↓
┆19┆┆9f┆┄┄nation.↲
↲
╞ chan_sh╞ : ┆84┆Pointer to dte_chan incarnation used by the ↓
┆19┆┆9f┆┄┄operating system.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.2.5╞ Semaphores and Message Flow.↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 13: Flow of messages to and from dte.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.2.6╞ Overview of Process Operation.↲
↲
╞ ┆84┆In this subsection an overview of the dte process operation is ↓
┆19┆┆89┆┄┄outlined either as flowcharts or in pseudo Real-Time Pascal code ↓
┆19┆┆89┆┄┄or in natural text.↲
↲
╞ ┆84┆A detailed description of channel set-up and clearing is given in ↓
┆19┆┆89┆┄┄subsection 4.2.7 and the hdlc event treatment in subsection 4.2.8.↲
↲
╞ The different state variables used in the description are:↲
↲
┆b0┆╞ dte_state ┆f0┆: see subsection 4.2.2.↲
↲
┆b0┆╞ proc_state ┆f0┆: p_exit╞ : ┆84┆exception procedure called in ↓
┆19┆┆a9┆┆81┆┄channel process↲
╞ ╞ p_idle╞ : ┆84┆channel process idle either remov┄↓
┆19┆┆a9┆┄┄ed or stopped (iremoved, inot_rem┄↓
┆19┆┆a9┆┄┄oved)↲
╞ ╞ p_active╞ : ┆84┆Virtual Call exsisting↲
╞ ╞ p_stopping╞ : ┆84┆channel process in stop phase (VC ↓
┆19┆┆a9┆┄┄clearing)↲
╞ ╞ p_restart╞ : DTE in restart phase↲
↲
┆b0┆╞ lcn_state╞ ┆f0┆: ch_ready╞ : logical channel idle↲
╞ ╞ ch_data╞ : Virtual Call exsisting↲
╞ ╞ ch_clearing╞ : Virtual Call is being cleared↲
↲
┆b0┆╞ line_state ┆f0┆: see subsection 4.2.2↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 14: Process dte, main flowchart.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆b0┆PART (A):↲
↲
┆84┆ In the initialization part, the following actions are performed:↲
↲
╞ - ┆84┆initialization of ┆b0┆get_clock┆f0┆ message and output zone,↲
╞ - ┆84┆writing the DTE version information on the console, if ↓
┆19┆┆8e┆┄┄test(4) = true (see subsection 6.2.1)↲
╞ - ┆84┆checking default values, process parameters and own dte ↓
┆19┆┆8e┆┄┄address↲
╞ - ┆84┆initialization of local, tracing and NC variables↲
╞ - ┆84┆initialization of tables:↲
╞ ╞ chan_table↲
╞ ╞ lcn_table↲
╞ ╞ hrec_table↲
╞ ╞ int_table↲
╞ ╞ user_table↲
╞ - buffer allocation↲
╞ ╞ sync_mess and restart_mess pools↲
╞ ╞ hdlc input pools↲
╞ ╞ X.25 control output pool↲
╞ ╞ internal event messages↲
╞ ╞ hdlc event pool↲
╞ ╞ internal header pool↲
╞ ╞ internal supervisor message pool↲
╞ ╞ break message↲
╞ - ┆84┆initialization (link, create and start) of children processes↲
╞ - ┆84┆sending ┆b0┆connect_lcp┆f0┆ to the NCP↲
╞ - ┆84┆sending ┆b0┆connect┆f0┆ and ┆b0┆event┆f0┆ messages to the HDLCLCP and initia┄↓
┆19┆┆8e┆┆82┆┄lization of all associated variables.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆PART (B):↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 15: Process dte, part (B) flowchart.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆PART (C):↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 16: Process dte, part (C) flowchart.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆PART (D):↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 17: Process dte, part (D) flowchart.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆PART (E):↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 18: Process dte, part (E) flowchart.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆PART (F):↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ * see ref. (4)↲
╞ Figure 19: Process dte, part (F) flowchart.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆PART (G):↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 20: Process dte, part (G) flowchart.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆PART (H):↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 21: Process dte, part (H) flowchart.↲
↲
↲
↲
┆b0┆┆b0┆PART (I):↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 22: Process dte, part (I) flowchart.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆PART (J):↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 23: Process dte, part (J) flowchart.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.2.7╞ Creation and Removal of dte_chan Process Incarnations.↲
↲
╞ ┆84┆As already mentioned a Virtual Call is serviced by one dte_chan ↓
┆19┆┆89┆┄┄process incarnation. The dte process performs the creation, con┄↓
┆19┆┆89┆┄┄nection to a VC, and removal of these incarnations by maintaining ↓
┆19┆┆89┆┄┄two tables each containing a state variable:↲
╞ - logical channel table (lcn_table(n).state)↲
╞ - channel process table (chan_table(n).proc_state)↲
↲
╞ ┆84┆After initialization of the DTE and exchange of RESTART packets on ↓
┆19┆┆89┆┄┄the DTE/DCE interface, all logical channels are in state ch_ready ↓
┆19┆┆89┆┄┄and all incarnations in state p_idle. An incarnation is created/┄↓
┆19┆┆89┆┄┄started either, when a user dte_call_req, or an X.25 packet on a ↓
┆19┆┆89┆┄┄logical channel in state ch_ready, is received. When the Virtual ↓
┆19┆┆89┆┄┄Call is cleared the associated dte_chan incarnation is stopped and ↓
┆19┆┆89┆┄┄the state becomes p_idle, and when the DTE performs an X.25 re┄↓
┆19┆┆89┆┄┄start all incarnations are stopped and removed.↲
↲
╞ ┆84┆Below are the connections between the different tables (lcn_table, ↓
┆19┆┆89┆┄┄chan_table, user_table, hrec_table and int_table) outlined (figure ↓
┆19┆┆89┆┄┄24) and sta┄te transition tables (table 4 and 5), including actions ↓
┆19┆┆89┆┄┄performed, for the two state variables are shown too.↲
↲
╞ ┆84┆In the figure an example with logical channel number 5 and 2nd in┄↓
┆19┆┆89┆┄┄carnation (2nd entry in chan_table) of dte_chan is used. The user ↓
┆19┆┆89┆┄┄has two active streams/Virtual Calls and the one shown is in the ↓
┆19┆┆89┆┄┄data phase.↲
↲
╞ ┆84┆The semaphore pointers in chan_table and hrec_table is updated ↓
┆19┆┆89┆┄┄every time a dte_chan process incarnation is created/started or ↓
┆19┆┆89┆┄┄stopped/removed, whereas in int_table they are initialized at ↓
┆19┆┆89┆┄┄start and kept. If a semaphore pointer in the hrec_table does ↓
┆19┆┆89┆┄┄not point to an active dte_chan incarnation it points to the main ↓
┆19┆┆89┆┄┄semaphore of the dte process in order not to loose any X.25 pack┄↓
┆19┆┆89┆┄┄ets.↲
↲
╞ ┆84┆A special case is logical channel 0, which at start up points to ↓
┆19┆┆89┆┄┄the main semaphore of the dte process and first changes when the ↓
┆19┆┆89┆┄┄line becomes connected. Then it is changed to point at the main ↓
┆19┆┆89┆┄┄semaphore of the dte_lcnzero process. When the line is disconnect┄↓
┆19┆┆89┆┄┄ed, it is again changed to point to the dte process.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 24: Snap shot of tables connections.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ proc_state:↲
╱04002d440c00060000000002015031400000000000000000000000000000000000000000000000000a17222d3843555f69737d8791ffffff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╞ ______________________________________________________________________↲
╞ state ↲
╞ ╞ p_exit╞ p_idle╞ p_active╞ p_stopping╞ p_restart ↲
╞ ┆a1┆ event ↲
↲
╞ ╞ p_exit╞ p_exit╞ p_exit╞ p_exit╞ p_exit ↲
╞ break_mess ↲
pac2 pac2 pac1 pac1 pac1 ↲
┆a1┆ ↲
↲
╞ ╞ ╞ p_active ↲
call_req ↲
inc. call ↲
pac3 ↲
╞ ┆a1┆ ↲
↲
╞ ╞ p_idle╞ p_idle╞ p_idle╞ p_idle╞ p_idle ↲
sync_mess ↲
u2<>ok ↲
pac4 pac4 pac4 pac4 pac4 ↲
╞ ┆a1┆ ↲
↲
╞ sync_mess╞ ?╞ ?╞ ?╞ ?╞ p_restart ↲
╞ u2 = ok ↲
u3 = user_ pac5 pac5 pac5 pac5 pac7 ↲
┆a1┆ term ↲
↲
╞ sync_mess╞ ?╞ ?╞ p_stopping╞ p_idle╞ p_idle ↲
╞ u2 = ok ↲
u3 = ok pac5 pac5 pac6 pac9 pac8 ↲
┆a1┆ ↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002015031400000000000000000000000000000000000000000000000000a17222d3843555f69737d8791ffffff04╱
↓
↲
╞ Table 4: ┆84┆Process dte, internal state/action table for a dte_chan ↓
┆19┆┆92┆┄┄incarnation.↲
↲
╞ actions:↲
↲
╞ pac1 : clear Virtual Call and print error message↲
╞ pac2 : print error message↲
╞ pac3 : ┆84┆create/start dte_chan incarnation and update tables, ↓
┆19┆┆95┆┄┄send ┆b0┆sync_mess↲
╞ pac4 : remove process and update tables↲
╞ pac5 : print error message and stop↲
╞ pac6 : ┆84┆signal ┆b0┆sync_mess┆f0┆ to dte_chan incarnation and update ↓
┆19┆┆95┆┆81┆┄hrec_table↲
╞ pac7 : signal ┆b0┆sync_mess┆f0┆ to dte_chan incarnation↲
╞ pac8 : remove process↲
╞ pac9 : stop process↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a19263340464b555f69737d8791ffff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
┆b0┆╞ lcn_state :↲
↲
╞ _______________________________________________________↲
╞ state ↲
╞ ╞ ch_ready╞ ch_data╞ ch_clearing ↲
╞ ┆a1┆ event ↲
↲
╞ ╞ ch_data ↲
call_req ↲
╞ ╞ lac1 ↲
╞ ┆a1┆ ↲
╞ ╞ ╞ ╞ ╞ ↲
╞ ╞ ch_data╞ ch_data╞ ch_clearing ↲
╞ inc.call╞ ╞ ╞ ╞ ↲
╞ ╞ lac4╞ lac2╞ lac5 ↲
╞ ┆a1┆ ↲
╞ ╞ ╞ ╞ ╞ ↲
╞ clear_req╞ ch_data╞ ch_data╞ ch_ready ↲
╞ ╞ ╞ ╞ ╞ ↲
╞ clear_conf╞ lac3╞ lac2╞ lac5 ↲
╞ ┆a1┆ ↲
╞ ╞ ╞ ╞ ╞ ↲
╞ ╞ ch_data╞ ch_data╞ ch_clearing ↲
X.25 packet╞ ╞ ╞ ╞ ↲
╞ ╞ lac3╞ lac2╞ lac5 ↲
╞ ┆a1┆ ↲
╞ sync_mess╞ ╞ ╞ ╞ ↲
╞ u2 = ok╞ ch_ready╞ ch_ready╞ ch_ready ↲
╞ u3 = ok╞ ╞ ╞ ╞ ↲
╞ p_state=╞ ╞ ╞ ╞ ↲
╞ ┆a1┆p_acitive ╞ ↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000002014b31400000000000000000000000000000000000000000000000000a19263340464b555f69737d8791ffff04╱
↓
↲
╞ Table 5: ┆84┆Process dte, internal state/action table for a logical ↓
┆19┆┆92┆┄┄channel.↲
↲
╞ actions:↲
↲
╞ lac1 : included in pac3↲
╞ lac2 : signal message to dte_chan incarnation↲
╞ lac3 : transmit CLEAR CONFIRMATION to the DCE↲
╞ lac4 : included in pac3↲
╞ lac5 : discard message↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.2.8╞ HDLC Event Handling.↲
↲
╞ ┆84┆All control of the HDLC driver/HDLCLCP is performed by the dte ↓
┆19┆┆89┆┄┄process. In order to perform this control the dte process main┄↓
┆19┆┆89┆┄┄tains a state variable, line_state, which is the DTE's wiew of the ↓
┆19┆┆89┆┄┄state of the line. The state may change every time an event is ↓
┆19┆┆89┆┄┄returned form the HDLC. In figure 25 a flowchart of the control is ↓
┆19┆┆89┆┄┄outlined and below is a state transition table for line_state ↓
┆19┆┆89┆┄┄shown.↲
↲
╞ ____________________________________________________↲
╞ ┆a1┆! event ! state !↲
╞ ┆a1┆! group ! hdlc number ! A ! B ! C ! D ! E !↲
╞ ┆a1┆! I ! 0 ! - ! A ! - ! A ! - !↲
╞ ┆a1┆! II ! 1,11 ! A ! B ! C ! D ! E !↲
╞ ┆a1┆! III ! 2,3,5,12 ! E ! E ! E ! - ! - !↲
╞ ┆a1┆! IV ! 4 ! E ! D ! E ! - ! - !↲
╞ ┆a1┆! V ! 6 ! E ! B ! E ! E ! E !↲
╞ ┆a1┆! VI ! 7,8,9,10 ! C ! B ! C ! C ! - !↲
╞ ┆a1┆! VII ! 13,14╞ ! E ! E ! E ! E ! E !↲
╞ ┆a1┆! VIII ! 15╞ ! A ! B ! C ! D ! E !↲
↲
╞ line_state:↲
╞ h_conn = A↲
╞ h_conn_ing = B↲
╞ h_disc_ing = C↲
╞ h_recv_disc = D↲
╞ h_disc = E↲
↲
╞ Table 6: Process dte, state transition table for line_state.↲
↲
╞ ┆84┆The compression of the line state table shown in ref. (9) is ob┄↓
┆19┆┆89┆┄┄tained by setting both the auto_connect and rnr_disc bits in the ↓
┆19┆┆89┆┄┄connect message to false and then group the events.↲
↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 25: Flowchart for HDLC event treatment.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆The DTE operates on four modem signals made avaible by the HDLC ↓
┆19┆┆89┆┄┄driver. This is ↲
↲
╞ - DTR set by the DTE↲
╞ - DSR╞ tested by the DTE↲
╞ - RTS set by the DTE↲
╞ - DCD tested by the DTE↲
↲
╞ ┆84┆For a more detailed description please see procedure ┆b0┆set_modem┆f0┆ ↓
┆19┆┆89┆┆81┆┄subsection 4.1.2.2.↲
↲
╞ ┆84┆It is possible to suspend this modem signals setting/testing by ↓
┆19┆┆89┆┄┄setting the parameter test_modem in the hdlc-param configuration ↓
┆19┆┆89┆┄┄record (subsection 4.2.1 and subsection 7.1.2) to false. In this ↓
┆19┆┆89┆┄┄case the signals are read only.↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
«index» formatlinie til RC manualer↲
┆14┆┆b3┆↲
┆14┆┆b3┆┆06┆- ┆0b┆ -↲
┆a1┆4.3╞ Description of dte_access.↲
↲
╞ ┆84┆The dte_access process is the User Interface of the DTE module as ↓
┆19┆┆89┆┄┄already described in section 2.↲
╞ The main purpose is:↲
↲
╞ 1) ┆84┆interfacing a user to the DTE module and an X.25 ↓
┆19┆┆8f┆┄┄communication↲
↲
╞ 2) ┆84┆establishing the connection between a (user) stream↲
and an X.25 logical channel.↲
↲
↲
┆a1┆4.3.1╞ Process Parameters.↲
↲
╞ ┆84┆PROCESS dte_access(↲
╞ VAR dte_ptr╞ : ! tap_pointer;↲
╞ VAR sup_ptr╞ : ! sempointer;↲
╞ VAR event_pool╞ : semaphore;↲
╞ VAR stream_vector: ! ch_sem_type;↲
╞ max_stream╞ : byte;↲
╞ VAR user_table╞ : u_table_type;↲
╞ VAR user_key╞ : semaphore;↲
╞ act_user_id_lgth : byte↲
╞ );↲
↲
╞ dte_prt╞ ╞ : ┆84┆Main semaphore pointer of the DTE module and ↓
┆19┆┆9f┆┄┄the dte_access process.↲
↲
╞ sup_ptr╞ ╞ : ┆84┆dte main semaphore pointer↲
↲
╞ event_pool╞ : ┆84┆DTE global event pool. Internal event buf┄↓
┆19┆┆9f┆┄┄fers are hanged up on this semaphore.↲
↲
╞ stream_vector╞ : ┆84┆Semaphore pointers to the dte_chan process ↓
┆19┆┆9f┆┄┄incarnations. Used to route user messages to ↓
┆19┆┆9f┆┄┄a dte_chan incarnation.↲
↲
╞ max_stream╞ : ┆84┆Maximum number of user streams the DTE is ↓
┆19┆┆9f┆┄┄able to serve.↲
↲
┆8c┆┄┆a9┆↓
╞ user_table╞ : ┆84┆Each connected user is described by an entry ↓
┆19┆┆9f┆┄┄in user_table. For a detailed description ↓
┆19┆┆9f┆┄┄please see subsection 4.1.1.1.↲
↲
╞ user_key╞ ╞ : Access semaphore to user_table.↲
↲
╞ act_user_id_lgth╞ : ┆84┆Actual user identification length. Please ↓
┆19┆┆9f┆┄┄refer to subsection 4.1.6.↲
↲
↲
┆a1┆4.3.2╞ States.↲
↲
╞ ┆84┆The dte_access maintains four state variables:↲
↲
╞ - dte_rec.dte_state╞ ╞ : state of the DTE module↲
↲
╞ - user_table.user_state╞ : ┆84┆state of a connected user/entry in ↓
┆19┆┆a9┆┄┄the user table↲
↲
╞ - stream_table.stream_state╞ : ┆84┆state of a user stream in the user ↓
┆19┆┆a9┆┄┄interface↲
↲
╞ - stream_table.intern_state╞ : ┆84┆state of a stream internal in the ↓
┆19┆┆a9┆┄┄process.↲
↲
↲
┆b0┆╞ dte_rec.dte_state:↲
↲
╞ ┆84┆Description of the individual states please refer to subsection ↓
┆19┆┆8c┆┄┄4.2.2.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 26: ┆84┆State transition graph for dte_state in process ↓
┆19┆┆94┆┄┄dte_access.↲
↲
┆b0┆╞ user_table.user_state:↲
↲
┆b0┆╞ free╞ ╞ ┆f0┆entry in user table free↲
↲
┆b0┆╞ w_resc╞ ╞ ┆84┆┆f0┆the dte_access process is awaiting resources ↓
┆19┆┆9d┆┆81┆┄(receive general) from the user↲
↲
┆b0┆╞ idle╞ ╞ ┆f0┆the user has no active streams↲
↲
┆b0┆╞ active╞ ╞ ┆f0┆the user has at least one active stream.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ________________________________________________________________↲
╞ state ┆82┆free w_resc idle active↲
╞ ┆a1┆ event ↲
╞ dte_ ╞ ┆82┆free w_resc active active↲
┆a1┆ call_req ↲
╞ dte_ ┆82┆free w_resc idle active↲
┆a1┆ wait_event ↲
dte_ ┆82┆free idle idle active ↲
┆a1┆ rec_gen ↲
dte_ ┆82┆w_resc w_resc idle active↲
┆a1┆ conn_user ↲
dte_ ┆82┆free free free active↲
┆a1┆ disc_user ↲
all streams ┆82┆idle↲
┆a1┆ cleared ↲
╞ X.25 incom. ┆82┆active active↲
┆a1┆ call ↲
↲
╞ Table 7: ┆84┆Process dte_access, state transition table for ↓
┆19┆┆92┆┄┄user_state.↲
↲
╞ ┆84┆In appendix C.1.1 the state/action table correlated with ↓
┆19┆┆89┆┄┄user_state is outlined.↲
↲
┆b0┆╞ stream_table.stream_state:↲
↲
┆b0┆╞ clear╞ ╞ ┆f0┆the entry in stream_table is free↲
↲
┆b0┆╞ w_uresp╞ ┆84┆┆84┆┆f0┆the stream has been cleared while waiting user ↓
┆19┆┆9d┆┆81┆┄response on an internal incoming call↲
↲
╞ ┆b0┆w_accp╞ ╞ ┆84┆┆84┆┆f0┆the dte_access process is awaiting user re┄↓
┆19┆┆9d┆┆81┆┄sponse on an internal incoming call↲
↲
┆b0┆╞ data╞ ╞ ┆f0┆the stream is ready for data transfer↲
↲
┆b0┆╞ u_clear╞ ┆f0┆the user has initiated the clearing phase↲
↲
↲
┆8c┆┄┆a7┆↓
┆b0┆╞ stream_table.intern_state:↲
↲
┆b0┆╞ cleared╞ ┆f0┆no active stream↲
↲
┆b0┆╞ waiting╞ ┆84┆┆f0┆the dte_access process is awaiting response ↓
┆19┆┆9d┆┆81┆┄from the dte process on a chan_start message↲
↲
╞ ┆b0┆xfer_data╞ ┆f0┆the stream is ready for data transfer↲
↲
┆b0┆╞ clearing╞ ┆84┆┆f0┆the stream has been cleared by the dte_chan ↓
┆19┆┆9d┆┆81┆┄incarnation, but an answer on 'chan_start' has ↓
┆19┆┆9d┆┆81┆┄not yet been received.↲
↲
↲
┆a1┆4.3.3╞ Semaphore and Reference Variables.↲
↲
╞ ┆84┆Variables of type 'sempointer' and 'tap_pointer' are mentioned in ↓
┆19┆┆89┆┄┄the semaphore subsection just as they were semaphores.↲
↲
↲
┆b0┆╞ ┆a1┆SEMAPHORES↲
↲
╞ testsem╞ ╞ : ┆84┆Semaphore used for queuing of ↓
┆19┆┆a9┆┄┄messages during internal test ↓
┆19┆┆a9┆┄┄of the dte_access process. Please ↓
┆19┆┆a9┆┄┄see section 6.2.↲
↲
╞ stream_table.suspend_sem╞ : ┆84┆Semaphore used to queue up user ↓
┆19┆┆a9┆┄┄messages until a dte_chan incarna┄↓
┆19┆┆a9┆┄┄tion is active.↲
↲
╞ stream_table.chanproc_sem╞ : ┆84┆Semaphore pointer to the associat┄↓
┆19┆┆a9┆┄┄ed dte_chan incarnation.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ┆a1┆REFERENCES↲
↲
╞ event_ref╞ ╞ ╞ : ┆84┆Working reference during event ge┄↓
┆19┆┆a9┆┄┄neration.↲
↲
╞ req_ref╞ ╞ ╞ : ┆84┆Holds the message under process┄↓
┆19┆┆a9┆┄┄ing.↲
↲
╞ key_ref╞ ╞ ╞ : ┆84┆Used to hold the key message du┄↓
┆19┆┆a9┆┄┄ring access to the user_table.↲
↲
╞ aref╞ ╞ ╞ : Working reference.↲
↲
╞ mref╞ ╞ ╞ : Working reference.↲
↲
╞ stream_table.internal_ref╞ : ┆84┆Hold either an internal incoming ↓
┆19┆┆a9┆┄┄call or internal clear message ↓
┆19┆┆a9┆┄┄while wait┄ing user response.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.3.4╞ Data Structures.↲
↲
╞ ┆84┆The following data structures used in the dte_access process are ↓
┆19┆┆89┆┄┄described elsewhere.↲
↲
╞ user_table╞ section 4.1.1.1↲
╞ stream_vector╞ section 4.1.1.2↲
↲
╞ ┆84┆Besides these the below described data structures are important ↓
┆19┆┆89┆┄┄for understanding the internal structure and work of the dte_ac┄↓
┆19┆┆89┆┄┄cess process↲
↲
╞ stream_table╞ ╞ : ┆84┆Each entry in this table describes ↓
┆19┆┆a9┆┄┄a user stream including routing ↓
┆19┆┆a9┆┄┄pointers to the associated ↓
┆19┆┆a9┆┄┄dte_chan incarnation. Type is ↓
┆19┆┆a9┆┄┄stream_type described below↲
↲
╞ channel_table╞ ╞ : ┆84┆Arrays of integers, which acts as ↓
┆19┆┆a9┆┄┄pointers to stream_table for a ↓
┆19┆┆a9┆┄┄conversion from dte_chan incarna┄↓
┆19┆┆a9┆┄┄tion numbers to entry numbers in ↓
┆19┆┆a9┆┄┄stream_table.↲
↲
↲
╞ stream_type = record↲
╞ stream_state╞ : state of the stream (see section 4.3.2)↲
╞ user_index╞ : index to user_table (byte)↲
╞ channel_no╞ : index to channel_table (byte)↲
╞ stream_event╞ : last stream event, type (byte)↲
╞ cause╞ ╞ : last stream event, cause (byte)↲
╞ diagnostic╞ : last stream event, diagnostic code (byte)↲
╞ no_of_lost_ev╞ : number of lost events (byte)↲
╞ chanproc_sem╞ : please refer to section 4.3.3 (sempointer)↲
╞ suspend_bsem╞ : please refer to section 4.3.3 (sempointer)↲
╞ internal_ref╞ : please refer to section 4.3.3 (sempointer)↲
╞ intern_state╞ : internal stream state (see section 4.3.2)↲
╞ end;↲
↲
↲
┆8c┆┄┆a8┆↓
┆a1┆4.3.5╞ Semaphores and Message Flow.↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 27: Flow of messages to and from dte_access.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.3.6╞ Overview of Process Operation.↲
↲
╞ ┆84┆In this subsection an overview of the dte_access process operation ↓
┆19┆┆89┆┄┄is outlined either as flowcharts or in pseudo Real-Time Pascal co┄↓
┆19┆┆89┆┄┄de or in natural text.↲
↲
╞ ┆84┆All received messages are divided into four groups:↲
↲
┆b0┆╞ group 1:↲
╞ ╞ - dte_call_req╞ ╞ (user)↲
╞ ╞ - dte_wait_event╞ ╞ (user)↲
╞ ╞ - dte_rec_gen╞ ╞ (user)↲
↲
┆b0┆╞ group 2:↲
┆b0┆╞ group 2u:↲
╞ ╞ - dte_rec_dedic╞ ╞ (user)↲
╞ ╞ - dte_send_data╞ ╞ (user)↲
╞ ╞ - dte_send_intrupt╞ ╞ (user)↲
╞ ╞ - dte_change_input╞ ╞ (user)↲
╞ ╞ - dte_reset_req╞ ╞ (user)↲
╞ ╞ - dte_sync_stream╞ ╞ (user)↲
╞ ╞ - dte_acc_inc_call╞ ╞ (user)↲
╞ ╞ - dte_clear_req╞ ╞ (user)↲
╞ ╞ - inc_s_event╞ ╞ (dte_chan)↲
╞ ╞ - stream_cleared╞ ╞ (dte_chan)↲
↲
┆b0┆╞ group 2x:↲
╞ ╞ - chan_start╞ ╞ (dte_access)↲
╞ ╞ - clear_event╞ ╞ (dte_chan)↲
↲
┆b0┆╞ group 3:↲
╞ ╞ - dte_conn_user╞ ╞ (user)↲
╞ ╞ - dte_disc_user╞ ╞ (user)↲
╞ ╞ - inc_call╞ ╞ (dte_chan)↲
╞ ╞ - restart_start╞ ╞ (dte)↲
╞ ╞ - restart_end╞ ╞ (dte)↲
╞ ╞ - inc_u_event╞ ╞ (dte_chan)↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 28: Process dte_access, main flowchart↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆PART (A):↲
↲
┆84┆In the initialization part, the only actions performed is ini┄↓
┆19┆┆89┆┄┄tialization of stream_table and channel_table and setting ↓
┆19┆┆89┆┄┄dte_rec.dte_state to 'net_down'.↲
↲
↲
┆b0┆PART (B):↲
↲
╞ In appendix C.1.1 the state/action table is shown.↲
↲
↲
┆b0┆PART (C):↲
and↲
┆b0┆PART (D)↲
↲
╞ In appendix C.1.2 a combined state/action table is shown↲
↲
↲
┆b0┆PART (E):↲
↲
╞ In appendix C.1.3 the state/action table is shown.↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.4╞ Description of dte_hrec↲
↲
╞ ┆84┆The dte_hrec process is the process in the DTE module handling the ↓
┆19┆┆89┆┄┄input buffers to/from the HDLC complex.↲
╞ The main purpose is:↲
↲
╞ 1) ┆84┆try to keep a specified number of input buffers at the HDLC ↓
┆19┆┆8f┆┄┄driver↲
↲
╞ 2) ┆84┆routing input buffers, received from the HDLC driver either ↓
┆19┆┆8f┆┄┄to a dte_chan incarnation, which is servicing the specifi┄↓
┆19┆┆8f┆┄┄ed (in the received data) logical channel or dte_lcnzero↲
↲
╞ 3) tracing the received X.25 packets.↲
↲
↲
┆a1┆4.4.1╞ Process Parameters.↲
↲
╞ PROCESS dte_hrec (↲
╞ VAR in_ptr╞ : ! tap_pointer;↲
╞ VAR sup_ptr,↲
╞ hdlc_ptr╞ : ! sempointer;↲
╞ VAR bigbuf,↲
╞ smallbuf,↲
╞ trace_buf╞ : ph_type;↲
╞ VAR event_pool╞ : semaphore;↲
╞ VAR chan_sem╞ : ! ch_sem_type;↲
╞ max_chan╞ : byte;↲
╞ bigsize╞ : integer;↲
╞ VAR trace_on╞ : ! boolean↲
);↲
↲
↲
╞ in_ptr╞ ╞ : dte_hrec main semaphore pointer↲
↲
╞ sup_ptr╞ ╞ : dte main semaphore pointer↲
↲
╞ hdlc_ptr╞ ╞ : Main semaphore pointer of the HDLCLCP module↲
↲
┆8c┆┄┆a7┆↓
╞ bigbuf╞ ╞ : Big buffer pool (see subsection 4.1.3)↲
↲
╞ smallbuf╞ ╞ : Small buffer pool (see subsection 4.1.3)↲
↲
╞ trace_buf╞ ╞ : ┆84┆Trace buffer pool (see subsection 4.1.3 and ↓
┆19┆┆9f┆┄┄section 6.1).↲
↲
╞ event_pool╞ : ┆84┆DTE global event pool. Internal event ↓
┆19┆┆9f┆┄┄buffers are hanged up on this semaphore.↲
↲
╞ chan_sem╞ ╞ : ┆84┆Semaphore pointers to the dte_chan ↓
┆19┆┆9f┆┄┄incarnations and dte_lcnzero process.↲
╞ ╞ ╞ ┆84┆Used to route input buffers received from ↓
┆19┆┆9f┆┄┄the HDLC driver. The pointers are changed ↓
┆19┆┆9f┆┄┄dynamically by the dte process.↲
↲
╞ max_chan╞ ╞ : ┆84┆Maximum number of X.25 logical channels.↲
↲
╞ bigsize╞ ╞ : Size in bytes of big buffers.↲
↲
╞ trace_on╞ ╞ : ┆84┆Boolean indicating whether the X.25 packet ↓
┆19┆┆9f┆┄┄flow shall be traced (true) or not (false). ↓
┆19┆┆9f┆┄┄Changed dynamically by the dte process.↲
↲
↲
┆a1┆4.4.2╞ States.↲
↲
╞ ┆84┆This process does not use any state variables.↲
↲
↲
┆a1┆4.4.3╞ Semaphore and Reference Variables.↲
↲
┆b0┆╞ ┆a1┆SEMAPHORES↲
↲
╞ trace_rec.wsem╞ : ┆84┆Answer semaphore used in the tracing ↓
┆19┆┆9f┆┄┄procedure (see subsection 4.1.2.5).↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ┆a1┆REFERENCES↲
↲
╞ key_ref╞ ╞ : ┆84┆Used to hold the key buffer during access to ↓
┆19┆┆9f┆┄┄pools.↲
↲
╞ mess_ref╞ ╞ : Holds the message under processing.↲
↲
╞ msg_ref╞ ╞ : Working reference.↲
↲
╞ help_ref╞ ╞ : Working reference in buffer pool requests.↲
↲
╞ req_buf╞ ╞ : Holds a buffer request message.↲
↲
╞ trace_rec.t_ref╞ : ┆84┆Working reference used in the tracing ↓
┆19┆┆9f┆┄┄procedure (see subsection 4.1.2.5).↲
↲
↲
┆a1┆4.4.4╞ Data Structures.↲
↲
╞ ┆84┆The following data structure used in the dte_hrec process is desc┄↓
┆19┆┆89┆┄┄ribed elsewhere.↲
↲
╞ chan_sem╞ section 4.1.1.2↲
↲
╞ ┆84┆Besides this the below described data structure is important for ↓
┆19┆┆89┆┄┄understanding the internal structure and work of the dte_hrec pro┄↓
┆19┆┆89┆┄┄cess.↲
↲
╞ x25_rec╞ : ┆84┆Contains the lowest (ltc) and highest (htc) ↓
┆19┆┆9f┆┄┄logical channel number for two way communi┄↓
┆19┆┆9f┆┄┄cation, and the associated index (ltci, ↓
┆19┆┆9f┆┄┄htci) to chan_sem.↲
╞ ╞ ╞ ┆84┆These variables are used to calculate the ↓
┆19┆┆9f┆┄┄index to chan_sem for a received logical ↓
┆19┆┆9f┆┄┄channel number (index = lcn-ltc+ltci) and to ↓
┆19┆┆9f┆┄┄check whether the channel number is inside ↓
┆19┆┆9f┆┄┄the assigned interval.↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.4.5╞ Semaphores and Message Flow.↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 29: Flow of messages to and from dte_hrec.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.4.6╞ Overview of Process Operation.↲
↲
╞ ┆84┆In this section an overview of the dte_hrec process operation is ↓
┆19┆┆89┆┄┄outlined either as flowcharts or in pseudo Real Time Pascal code ↓
┆19┆┆89┆┄┄or in natural text.↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ * packet_id in (data, incoming_call, call_connected, diagnostic)↲
↲
╞ Figure 30: Process dte_hrec, main flowchart.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆PART (A):↲
↲
┆84┆In the initialization part, the only action performed is allo┄↓
┆19┆┆89┆┄┄cation and initialization of a buffer request message.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.5╞ Description of dte_lcnzero.↲
↲
╞ ┆84┆The dte_lcnzero process is the process in the DTE module servicing ↓
┆19┆┆89┆┄┄the X.25 logical channel zero.↲
╞ The main purpose is:↲
↲
╞ 1) handling the channel zero functions:↲
╞ - restart request↲
╞ - restart indication↲
╞ - restart confirmation↲
╞ - diagnostic↲
↲
╞ ┆84┆If the RESTART INDICATION, RESTART CONFIRMATION or DIAGNOSTIC pac┄↓
┆19┆┆89┆┄┄kets have a logical channel number different from zero the packet ↓
┆19┆┆89┆┄┄is (by dte_hrec) routed to the dte_chan incarnation handling the ↓
┆19┆┆89┆┄┄actual logical channel.↲
↲
↲
┆a1┆4.5.1╞ Process Parameters.↲
↲
╞ PROCESS dte_lcnzero (↲
╞ VAR in_ptr╞ : ! tap_pointer;↲
╞ VAR hdlc_ptr,↲
╞ operator,↲
╞ sup_ptr╞ : ! sempointer;↲
╞ VAR event_pool↲
╞ testsem╞ : semaphore;↲
╞ VAR bigbuf↲
╞ smallbuf↲
╞ x25_buf╞ : ph_type;↲
╞ bigsize╞ : integer;↲
╞ VAR test╞ : ! testrectype;↲
╞ VAR global_time : ! integer↲
╞ );↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ in_ptr╞ ╞ : dte_lcnzero main semaphore pointer.↲
↲
╞ hdlc_ptr╞ ╞ : ┆84┆Main semaphore pointer of the HDLCLCP ↓
┆19┆┆9f┆┄┄module.↲
↲
╞ operator╞ ╞ : ┆84┆Main semaphore pointer of the operator ↓
┆19┆┆9f┆┄┄process.↲
↲
╞ sup_ptr╞ ╞ : ┆84┆Main semaphore pointer of the dte process.↲
↲
╞ event_pool╞ : ┆84┆DTE global event pool. Internal event ↓
┆19┆┆9f┆┄┄buffers are hanged up on this semaphore.↲
↲
╞ testsem╞ ╞ : ┆84┆Semaphore used as a DTE global test buffer ↓
┆19┆┆9f┆┄┄pool.↲
↲
╞ bigbuf╞ ╞ : Big buffer pool (see subsection 4.1.3).↲
↲
╞ smallbuf╞ ╞ : Small buffer pool (see subsection 4.1.3).↲
↲
╞ x25_buf╞ ╞ : ┆84┆X.25 control output packet buffer pool (see ↓
┆19┆┆9f┆┄┄subsection 4.1.3).↲
↲
╞ bigsize╞ ╞ : Size in bytes of big buffers.↲
↲
╞ test╞ ╞ : Testbits array (see section 6.2).↲
↲
╞ global_time╞ : ┆84┆DTE global time used to time stamp test ↓
┆19┆┆9f┆┄┄records.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.5.2╞ States.↲
↲
╞ ┆84┆The dte_lcnzero process maintains a state variable 'p_level_state' ↓
┆19┆┆89┆┄┄which reflects the state of the X.25 packet level (DTE module ↓
┆19┆┆89┆┄┄state). Furthermore the process maintains a state variable in con┄↓
┆19┆┆89┆┄┄nection with timer t20 (restart timer).↲
↲
┆b0┆╞ p_level_state:↲
↲
╞ ┆84┆description of the individual states please refer to subsection ↓
┆19┆┆8c┆┄┄4.2.2.↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 31: ┆84┆State transition graph for p_level_state in process ↓
┆19┆┆94┆┄┄dte_lcnzero.↲
↲
↲
┆b0┆╞ tt20.state:↲
↲
╞ please refer to subsection 4.1.4.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.5.3╞ Semaphore and Reference Variables.↲
↲
┆b0┆╞ ┆a1┆SEMAPHORES↲
↲
╞ timer_sem╞ : Answer semaphore for timer regret messages.↲
↲
╞ wait_buf_sem╞ : ┆84┆Answer semaphore for buffer request mes┄↓
┆19┆┆9f┆┄┄sages.↲
↲
↲
┆b0┆╞ ┆a1┆REFERENCES↲
↲
╞ book_ref╞ : Holds a timer regret message.↲
↲
╞ help_ref╞ : Working reference.↲
↲
╞ key_ref╞ : ┆84┆Used to hold the key message during access ↓
┆19┆┆9f┆┄┄to pools.↲
↲
╞ mess_ref╞ : Holds the message under processing.↲
↲
╞ supmess_ref╞ : ┆84┆Holds an internal message for communication ↓
┆19┆┆9f┆┄┄with the dte process.↲
↲
╞ wait_buf╞ : Holds a buffer request message.↲
↲
↲
┆a1┆4.5.4╞ Data Structures.↲
↲
╞ ┆84┆The following data structures used in the dte_lcnzero process are ↓
┆19┆┆89┆┄┄de┄scribed elsewhere:↲
↲
╞ x25_param╞ section 4.1.1.3↲
╞ tt20╞ ╞ section 4.1.4↲
╞ testbuf╞ section 6.2.4.2↲
↲
╞ ┆84┆Besides these the dte_lcnzero process uses a zone (outzone) for ↓
┆19┆┆89┆┄┄printing of error messages on the console.↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.5.5╞ Semaphores and Message Flow.↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 32: Flow of messages to and from dte_lcnzero.↲
┆8c┆┄┆a7┆↓
┆a1┆4.5.6╞ Overview of Process Operation.↲
↲
╞ ┆84┆In this section an overview of the dte_lcnzero process operation ↓
┆19┆┆89┆┄┄is outlined either as flowcharts or in pseudo Real-Time Pascal ↓
┆19┆┆89┆┄┄code or in natural text.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 33: Process dte_lcnzero, main flowchart.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆PART (A):↲
↲
┆84┆In the initialization part the following actions are performed.↲
↲
╞ - ┆84┆initialization of regret, buffer request, and supervisor mes┄↓
┆19┆┆8e┆┄┄sages↲
╞ - initialization of state variables↲
╞ - initialization of variable 'x25_param'↲
↲
↲
┆b0┆PART (B):↲
↲
┆84┆The state_machine is implemented as an state/action table, which ↓
┆19┆┆89┆┄┄is shown in appendix C.2, and a short description of the actions ↓
┆19┆┆89┆┄┄are given here too.↲
↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
«index» formatlinie til RC manualer↲
┆14┆┆b3┆↲
┆14┆┆b3┆┆06┆- ┆0b┆ -↲
┆a1┆4.6 Description of dte_chan.↲
↲
╞ ┆84┆The dte_chan process is the process in the DTE module servicing an ↓
┆19┆┆89┆┄┄X.25 Virtual Call/User stream.↲
╞ The main purpose is:↲
↲
╞ 1) ┆84┆┆84┆Providing the services of an X.25 Virtual Call to a user, ↓
┆19┆┆8f┆┄┄i.e. implementing the main part of the X.25 recommendation.↲
↲
↲
┆a1┆4.6.1╞ Process Parameters.↲
↲
╞ PROCESS dte_chan(↲
╞ VAR in_ptr,↲
╞ sync_ptr╞ : ! tap_pointer;↲
╞ VAR dte_int_ptr,↲
╞ sup_ptr,↲
╞ hdlc_ptr,↲
╞ timeout_ptr,↲
╞ gen_bsem╞ : ! sempointer;↲
╞ VAR bigbuf,↲
╞ smallbuf,↲
╞ x25_buf╞ : ph_type;↲
╞ VAR breaksem↲
╞ event_pool,↲
╞ testsem╞ : semaphore;↲
╞ VAR b_upd_stat: : ! boolean;↲
╞ own_adr_rec╞ : adr_rec_type;↲
╞ x25_datasize ╞ : integer;↲
╞ VAR test╞ : ! testrectype;↲
╞ VAR global_time╞ : ! integer↲
╞ );↲
↲
╞ in_ptr╞ ╞ : dte_chan main semaphore pointer.↲
↲
╞ sync_ptr╞ ╞ : ┆84┆dte_chan synchronization semaphore pointer ↓
┆19┆┆9f┆┄┄(see subsection 4.2.7).↲
↲
╞ dte_int_ptr╞ : ┆84┆Main semaphore pointer of the dte_access ↓
┆19┆┆9f┆┄┄process.↲
↲
┆8c┆┄┆a9┆↓
╞ sup_ptr╞ ╞ : Main semaphore pointer of the dte process.↲
↲
╞ hdlc_ptr╞ ╞ : ┆84┆Main semaphore pointer of the HDLCLCP mo┄↓
┆19┆┆9f┆┄┄dule.↲
↲
╞ timeout_ptr╞ : ┆84┆Main semaphore pointer of the TIMEOUT mo┄↓
┆19┆┆9f┆┄┄dule.↲
↲
╞ gen_bsem╞ ╞ : ┆84┆General input semaphore pointer for the as┄↓
┆19┆┆9f┆┄┄sociated user.↲
↲
╞ bigbuf╞ ╞ : Big buffer pool (see subsection 4.1.3).↲
↲
╞ smallbuf╞ ╞ : Small buffer pool (see subsection 4.1.3).↲
↲
╞ x25_buf╞ ╞ : ┆84┆X.25 control output packets buffer pool (see ↓
┆19┆┆9f┆┄┄subsection 4.1.3).↲
↲
╞ breaksem╞ ╞ : ┆84┆Semaphore holding the break message used in ↓
┆19┆┆9f┆┄┄the exception procedure.↲
↲
╞ event_pool╞ : ┆84┆DTE global event pool. Internal event buf┄↓
┆19┆┆9f┆┄┄fers are queued at this semaphore.↲
↲
╞ testsem╞ ╞ : ┆84┆Semaphore used as a DTE global test buffer ↓
┆19┆┆9f┆┄┄pool.↲
↲
╞ b_upd_stat╞ : ┆84┆If true update of statistical counters shall ↓
┆19┆┆9f┆┄┄be performed.↲
↲
╞ own_adr_rec╞ : Own network address (see subsection 4.1.6).↲
↲
╞ x25_datasize╞ : ┆84┆The maximum length of the data field in an ↓
┆19┆┆9f┆┄┄X.25 data packet.↲
↲
╞ test╞ ╞ : Testbits arrray (see section 6.2).↲
↲
╞ global_time╞ : ┆84┆DTE global time used to time stamp test re┄↓
┆19┆┆9f┆┄┄cords.↲
↲
↲
┆8c┆┄┆a9┆↓
┆a1┆4.6.2╞ States.↲
↲
╞ ┆84┆The dte_chan process operates mainly on one state variable, ↓
┆19┆┆89┆┄┄chan_rec.chan_state. Furthermore it uses a state variable for each ↓
┆19┆┆89┆┄┄timer (t11m, t12m, t21, t22, t23, t30 and t31) needed. For a de┄↓
┆19┆┆89┆┄┄tailed description of the timer states please refer to subsection ↓
┆19┆┆89┆┄┄4.1.4.↲
↲
┆b0┆╞ chan_rec.chan_state↲
↲
┆b0┆╞ xidle╞ ╞ ┆f0┆: the channel is in ready state↲
┆b0┆╞ xdtecall╞ ┆f0┆: ┆84┆the DTE is awaiting DCE response on a CALL ↓
┆19┆┆9f┆┆81┆┄REQUEST↲
┆b0┆╞ xdcecall╞ ┆f0┆: ┆84┆the DTE is awaiting user response on an IN┄↓
┆19┆┆9f┆┆81┆┄COMING CALL↲
┆b0┆╞ xdteclear╞ ┆f0┆: ┆84┆the DTE is awaiting DCE response on a CLEAR ↓
┆19┆┆9f┆┆81┆┄REQUEST↲
┆b0┆╞ xretclear╞ ┆f0┆: ┆84┆a CLEAR REQUEST has been retransmitted at ↓
┆19┆┆9f┆┆81┆┄least once↲
┆b0┆╞ xdata╞ ╞ ┆f0┆: ┆84┆the DTE and DCE is in the data phase and ↓
┆19┆┆9f┆┆81┆┄both ready↲
┆b0┆╞ xdata_wic╞ ┆f0┆: ┆84┆as xdata and the DTE is awaiting INTERRUPT ↓
┆19┆┆9f┆┆81┆┄CONFIRMATION↲
┆b0┆╞ wsync╞ ╞ ┆f0┆: ┆84┆as xdata and the DTE is awaiting user syn┄↓
┆19┆┆9f┆┆81┆┄chronization on a reset event↲
┆b0┆╞ ndte╞ ╞ ┆f0┆: as xdata, but the DTE is not ready↲
┆b0┆╞ ndte_wic╞ ┆f0┆: as xdata_wic, but the DTE is not ready↲
┆b0┆╞ ndte_wsync╞ ┆f0┆: as wsync, but the DTE is not ready↲
┆b0┆╞ ndce╞ ╞ ┆f0┆: as xdata, but the DCE is not ready↲
┆b0┆╞ ndce_wic╞ ┆f0┆: as xdata_wic, but the DCE is not ready↲
┆b0┆╞ ndce_wsync╞ ┆f0┆: as wsync, but the DCE is not ready↲
┆b0┆╞ ndcte╞ ╞ ┆f0┆: as xdata, but the DTE and DCE are not ready↲
┆b0┆╞ ndcte_wic╞ ┆f0┆: ┆84┆as xdata_wic, but the DTE and DCE are not ↓
┆19┆┆9f┆┆81┆┄ready↲
┆b0┆╞ ndctewsync╞ ┆f0┆: ┆84┆as wsync, but the DTE and DCE are not ready↲
┆b0┆╞ xreset╞ ╞ ┆f0┆: ┆84┆RESET INDICATION received from the DCE, the ↓
┆19┆┆9f┆┆81┆┄DTE is awaiting user response, and no RESET ↓
┆19┆┆9f┆┆81┆┄CONFIRMATION is transmitted to the DCE yet↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ureset╞ ╞ ┆f0┆: ┆84┆dte_reset_req received from the user, the ↓
┆19┆┆9f┆┆81┆┄DTE is awaiting DCE confirmation↲
┆b0┆╞ ereset╞ ╞ ┆f0┆: ┆84┆the DTE has reset the Virtual Call, and is ↓
┆19┆┆9f┆┆81┆┄awaiting both user response and DCE confir┄↓
┆19┆┆9f┆┆81┆┄mation.↲
↲
╞ ┆84┆In appendix C.3 state transitions tables for the state variable is ↓
┆19┆┆89┆┄┄outlined.↲
↲
↲
┆a1┆4.6.3╞ Semaphores and Reference Variables.↲
↲
╞ ┆84┆Variables of type 'sempointer' and 'tap_pointer' are mentioned in ↓
┆19┆┆89┆┄┄the semaphore subsection just as they were semaphores.↲
↲
┆b0┆╞ ┆a1┆SEMAPHORES↲
↲
╞ hardwait╞ : ┆84┆Semaphore used in cases where hardwait is ↓
┆19┆┆9f┆┄┄required and as answer semaphore for buffer ↓
┆19┆┆9f┆┄┄requests.↲
╞ exsem╞ ╞ : Semaphore used in the exception procedure.↲
╞ local_insem1╞ : Local input semaphore number 1.↲
╞ local_insem2╞ : Local input semaphore number 2.↲
╞ own_buf_sem╞ : Used to queue X.25 output headers.↲
╞ rdata_sem╞ : ┆84┆Used to queue dedicated input buffers from ↓
┆19┆┆9f┆┄┄the user.↲
╞ s_sdata_sem╞ : ┆84┆Used to queue not yet processed user ↓
┆19┆┆9f┆┄┄dte_send_data messages.↲
╞ s_sint_sem╞ : ┆84┆Used to queue not yet processed user ↓
┆19┆┆9f┆┄┄dte_send_intrupt messages.↲
╞ timer_sem╞ : Answer semaphore for timer requests.↲
╞ user_int_sem╞ : ┆84┆Local input semaphore for user ↓
┆19┆┆9f┆┄┄dte_send_intrupt messages.↲
╞ w_sint_sem╞ : ┆84┆Holds one unacknowledge user ↓
┆19┆┆9f┆┄┄dte_send_intrupt message.↲
╞ w_x25data_sem╞ : ┆84┆Used to temporary queue X.25 DATA packets ↓
┆19┆┆9f┆┄┄(received) in state ndte.↲
╞ local_in.ptr╞ : ┆84┆Semaphore pointer to the actual local input ↓
┆19┆┆9f┆┄┄semaphore.↲
↲
↲
┆8c┆┄┆a9┆↓
┆b0┆╞ ┆a1┆REFERENCES↲
↲
╞ book_upd_ref╞ : Holds an timer booking/updating message.↲
╞ event_ref╞ : Working reference during event generation.↲
╞ key_ref╞ : ┆84┆Holds the key message during buffer pool ac┄↓
┆19┆┆9f┆┄┄cess.↲
╞ mess_ref╞ : Holds the message under processing.↲
╞ req_ref╞ : Working reference.↲
╞ reset_ref╞ : ┆84┆Used to temporary queue a user dte_reset_req ↓
┆19┆┆9f┆┄┄or dte_sync_stream message.↲
╞ sync_ref╞ : Holds the synchronization message.↲
╞ timer_ref╞ : Working reference during start of a timer.↲
╞ user_ref╞ : ┆84┆Used to temporary queue a user dte_call_req ↓
┆19┆┆9f┆┄┄or dte_clear_req message.↲
╞ wait_buf╞ : Working reference during buffer requests.↲
╞ workref╞ : Working reference.↲
╞ x25_ref╞ : Holds temporary the X.25 output buffer.↲
╞ not_ack_data(n).↲
╞ buf_ref : ┆84┆Holds a returned but yet not acknowledge ↓
┆19┆┆9f┆┄┄user dte_send_data buffer. The buffer is re┄↓
┆19┆┆9f┆┄┄turned when all preciding 'packets' and it ↓
┆19┆┆9f┆┄┄self are acknowledge.↲
↲
┆a1┆4.6.4╞ Data Structures.↲
↲
╞ ┆84┆The following data structures used in the dte_chan process are de┄↓
┆19┆┆89┆┄┄scribed elsewhere.↲
↲
╞ dte_timers╞ section 4.1.4↲
╞ x25_param╞ section 4.1.1.3↲
╞ sav_x25_param╞ section 4.1.1.3↲
╞ testbuf╞ section 6.2.4.3↲
↲
╞ ┆84┆The variable dte_timers is an array of 7 elements, where each ele┄↓
┆19┆┆89┆┄┄ment is described in section 4.1.4.↲
↲
╞ ┆84┆Besides these the below described data structures are important ↓
┆19┆┆89┆┄┄for understanding the internal structure and work of the dte_chan ↓
┆19┆┆89┆┄┄process.↲
↲
┆8c┆┄┆a8┆↓
╞ chan_rec╞ ╞ : ┆84┆Record containing all relevant information ↓
┆19┆┆9f┆┄┄concerning the actual serviced logical chan┄↓
┆19┆┆9f┆┄┄nel. The type is ch_rec_type.↲
↲
╞ ch_rec_type = record↲
╞ ╞ chan_state╞ : c_state_type;↲
╞ ╞ sem_index╞ : integer;↲
╞ ╞ stream_no╞ : byte;↲
╞ ╞ local_user╞ : local_adr_type;↲
╞ ╞ user_no,↲
╞ ╞ multi_buffer,↲
╞ ╞ rcv_buf_type╞ : byte;↲
╞ ╞ s_prio╞ : 0..7;↲
╞ ╞ remote_dte╞ : adr_rec_type;↲
╞ ╞ w_rec╞ : window_rec_desc;↲
╞ ╞ t30_norm,↲
╞ ╞ ack_timer╞ : integer;↲
╞ ╞ stream_status╞ : stat_rec_type;↲
╞ ╞ f_field_lgth╞ : byte;↲
╞ ╞ f_field╞ : faci_type;↲
╞ ╞ end;↲
↲
╞ chan_state╞ : ┆84┆State of the logical channel viewed by the ↓
┆19┆┆9f┆┄┄DTE (see subsection 4.6.2).↲
╞ sem_index╞ : ┆84┆Index to the dte_chanxxx main semaphore ↓
┆19┆┆9f┆┄┄area (see subsection 4.1.1.2).↲
╞ stream_no╞ : ┆84┆The associated stream number (see subsection ↓
┆19┆┆9f┆┄┄4.1.5).↲
╞ local_user╞ : ┆84┆The identification of the user in semi oc┄↓
┆19┆┆9f┆┄┄tets and the length of this identification ↓
┆19┆┆9f┆┄┄(see subsection 4.1.6).↲
╞ user_no╞ : User number in the DTE.↲
╞ multi_buffer╞ : ┆84┆The indicated (by user) maximum degree of ↓
┆19┆┆9f┆┄┄multibuffering on output.↲
╞ rev_buf_type╞ : ┆84┆Defines the type of input buffers, 1 = dedi┄↓
┆19┆┆9f┆┄┄cated input, 0 = general input (see ref. ↓
┆19┆┆9f┆┄┄(3)).↲
╞ s_prio╞ ╞ : ┆84┆The indicated priority divided by 32 to get ↓
┆19┆┆9f┆┄┄a number in (0..7), which is accepted by the ↓
┆19┆┆9f┆┄┄HDLC driver.↲
┆8c┆┄┆a8┆↓
╞ remote_dte╞ : ┆84┆The address of the remote DTE (see subsec┄↓
┆19┆┆9f┆┄┄tion 4.1.6).↲
╞ w_rec╞ ╞ : ┆84┆Record containing all information for the ↓
┆19┆┆9f┆┄┄window mechanism (see subsection 4.6.8).↲
╞ t30_norm╞ : The value of t30 (idle timer).↲
╞ ack_timer╞ : ┆84┆The value of acknowledge timer. This is used ↓
┆19┆┆9f┆┄┄to specify the maximum timer period from re┄↓
┆19┆┆9f┆┄┄ceival of a packet to it is acknowledged.↲
╞ stream_status╞ : ┆84┆Record containing stream/channel status in┄↓
┆19┆┆9f┆┄┄formation for internal use. The type is de┄↓
┆19┆┆9f┆┄┄fined in the external DTE environment ↓
┆19┆┆9f┆┄┄XDTEENV (appendix B.2).↲
╞ f_field_lgth╞ : X.25 facility field length.↲
╞ f_field╞ : X.25 facilities.↲
↲
↲
╞ not_ack_data╞ : ┆84┆This record structure is used to secure that ↓
┆19┆┆9f┆┄┄the user output buffers are returned in the ↓
┆19┆┆9f┆┄┄same sequence as received and only when they ↓
┆19┆┆9f┆┄┄are acknowledged by the DCE. The type and ↓
┆19┆┆9f┆┄┄function are described in subsection 4.6.9.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.6.5╞ Semaphores and Message Flow.↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 34: Flow of messages to and from dte_chan.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4.6.6╞ Overview of Process Operation.↲
↲
╞ ┆84┆In this section an overview of the dte_chan process operation is ↓
┆19┆┆89┆┄┄outlined either as flowcharts or in pseudo Real-Time Pascal code ↓
┆19┆┆89┆┄┄or in natural text.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 35: Process dte_chan, main flowchart.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆As shown in the flowchart (figure 35) the initialization is sepe┄↓
┆19┆┆89┆┄┄rated in two part, one concerning general process variables (PART ↓
┆19┆┆89┆┄┄(A)) and one concerning logical channel variables (PART (B)).↲
↲
↲
┆b0┆PART (A):↲
↲
╞ general process variables:↲
╞ - chan_rec.chan_state (for test purpose)↲
╞ - timer- and buffer allocation messages↲
╞ - local input sempointer↲
╞ - test buffer pointers↲
╞ - variable chan_active (:= false).↲
↲
↲
┆b0┆PART (B):↲
↲
logical channel variables:↲
╞ - special variables↲
╞ - not_ack_data↲
╞ - timer array↲
╞ - chan_rec↲
╞ - logical group and number in x25_param↲
╞ - window variables↲
╞ (the last three from the sync buffer).↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆PART (C):↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 36: Process dte_chan, part (C) flowchart.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆PART (D):↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 37: Process dte_chan, part (D) flowchart.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆81┆PART (E):↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 38: Process dte_chan, part (E) flowchart.↲
↲
┆b0┆PART (F):↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 39: Process dte_chan, part (F) flowchart.↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆PART (G):↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 40: Process dte_chan, part (G) flowchart.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆PART (H):↲
↲
╞ ┆84┆If general input is used the message is returned with result ↓
┆19┆┆89┆┄┄'fct_not_allw',↲
╞ otherwise↲
╞ - ┆84┆if state is waiting user confirmation (xreset, wsync, ↓
┆19┆┆8b┆┄┄ndce_wsync, ndte_wsync, ndctewsync, ereset) the message is re┄↓
┆19┆┆8b┆┄┄turned with 'not_processed',↲
╞ - ┆84┆if state is dte not ready and/or window closed in data state ↓
┆19┆┆8b┆┄┄(xdata, xdata_wic, ndce, ndce_wic, ndte, ndte_wic, ndcte, ↓
┆19┆┆8b┆┄┄ndcte_wic) and enough resources are received the state machine ↓
┆19┆┆8b┆┄┄is called (PART (I)) to open the window,↲
╞ - ┆84┆if state is dte ready and waiting resources (send_rnr = true) ↓
┆19┆┆8b┆┄┄and enough resources are received the state machine is called ↓
┆19┆┆8b┆┄┄(PART (I)) to open the window,↲
╞ - ┆84┆if state is dte ready (xdata, xdata_wic, ndce, ndce_wic) and the ↓
┆19┆┆8b┆┄┄window has been closed the state machine is called (PART (I)) to ↓
┆19┆┆8b┆┄┄open the window.↲
↲
┆b0┆↲
┆b0┆PART (I):↲
↲
╞ ┆84┆The procedure ┆b0┆state_machine(event, current_state)┆f0┆ is called in ↓
┆19┆┆89┆┆81┆┄order to perform the needed action and get the next state.↲
┆84┆↲
↲
┆b0┆PART (K):↲
↲
┆84┆An NC request is received. The specified operation is performed ↓
┆19┆┆89┆┄┄and the buffer returned to the NCP. 'Sense channel' and 'get chan┄↓
┆19┆┆89┆┄┄nel statistics' are the only LCP operations performed by the ↓
┆19┆┆89┆┄┄dte_chan process.↲
↲
╞ ┆84┆If not any of these an error in the dte process has occured.↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆PART (L):↲
↲
╞ ┆84┆The stop alogrithm contains the following steps:↲
↲
╞ 1. ┆84┆The sync_mess is returned to dte with u2 = ok and u3 = ↓
┆19┆┆90┆┄┄user_term.↲
╞ 2. ┆84┆The dte_chan process awaits the returnal of the sync_mess ↓
┆19┆┆90┆┄┄at the sync semaphore.↲
╞ 3. ┆84┆The dte changes the sempointer in the hrec_table.↲
╞ 4. ┆84┆The dte signals the sync_mess to the dte_chan process.↲
╞ 5. ┆84┆The dte_chan proccess empties its local semaphores, its in┄↓
┆19┆┆90┆┄┄put (main) semaphore, releases the X.25 output headers, ↓
┆19┆┆90┆┄┄sets the local input semaphore to number 1, and returns ↓
┆19┆┆90┆┄┄the sync_mess with u2 = ok and u3 = ok, before waiting at ↓
┆19┆┆90┆┄┄the sync semaphore for at new start indication.↲
↲
↲
┆a1┆4.6.7╞ Description of dte_chan local input semaphores.↲
↲
╞ ┆84┆As already mentioned the dte_chan process has two local input se┄↓
┆19┆┆89┆┄┄maphores. These are used in order to be able to seperate the dif┄↓
┆19┆┆89┆┄┄ferent input messages received at the main input semaphore. In or┄↓
┆19┆┆89┆┄┄der to not always check on a number to find the actual semaphore a ↓
┆19┆┆89┆┄┄record type is defined (insem_type). The variable (local_in) of ↓
┆19┆┆89┆┄┄this type contains a sempointer (to the actual semaphore) and the ↓
┆19┆┆89┆┄┄number of the semaphore (1 or 2).↲
↲
╞ ┆84┆In the local procedures ┆b0┆ret_inuserb, ret_wsdata┆f0┆ the not actual se┄↓
┆19┆┆89┆┆81┆┄maphore is used as a queue semaphore and at returnal from the pro┄↓
┆19┆┆89┆┆81┆┄cedures this semaphore becomes the actual input semaphore:↲
↲
╞ ┆b0┆before call: ┆f0┆local_in↲
local_insem1↲
↲
↲
╞ ╞ ╞ 1╞ ╞ local_insem2↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ in the procedure:↲
╞ ╞ ╞ actual_sem = local_insem1↲
╞ ╞ ╞ next_sem = local_insem2↲
↲
┆b0┆╞ after return:┆f0┆ local_in↲
╞ ╞ ╞ ╞ ╞ local_insem1↲
↲
╞ ╞ ╞ 2╞ ╞ local_insem2↲
↲
↲
┆a1┆4.6.8╞ The Strategy for Acknowledgement of Data Packets.↲
↲
╞ ┆84┆Because of the correlation of credit and acknowledgement in the ↓
┆19┆┆89┆┄┄X.25 recommendation, an acknowledgement cannot be sent without at ↓
┆19┆┆89┆┄┄the same time giving credit to more data. This mechanism is in the ↓
┆19┆┆89┆┄┄dte_chan process administrated by defining a window descriptor re┄↓
┆19┆┆89┆┄┄cord (see below). The window size is the maximum number of out┄↓
┆19┆┆89┆┄┄standing packets, and the lower window edge is the last acknowled┄↓
┆19┆┆89┆┄┄ged packet plus 1, i.e. the first unacknowledge packet.↲
↲
╞ ┆84┆The window description record (chan_rec.w_rec) contains the follo┄↓
┆19┆┆89┆┄┄wing fields:↲
↲
╞ w_recv (bit 3) : window size for receiving↲
╞ w_xmit ( - )╞ : window size for transmitting↲
╞ slw ( - ) : lower window edge for sending↲
╞ rlw ( - ) : lower window edge for receiving↲
╞ nsps ( - ) : next P(S) to be sent↲
╞ lrps ( - ) : last received P(S)↲
╞ rdataqueue (integer): ┆84┆number of queued dedicated user input buf┄↓
┆19┆┆9f┆┄┄fers. If mode is general-input rdataqueue ↓
┆19┆┆9f┆┄┄equals w_recv+1 allways.↲
╞ init_phase (boolean): ┆84┆indicates the initial phase where the normal ↓
┆19┆┆9f┆┄┄algorithm does not work, i.e. speciel calcu┄↓
┆19┆┆9f┆┄┄lations in the procedure w_algorithm are ↓
┆19┆┆9f┆┄┄performed.↲
↲
╞ ┆84┆The acknowledgement strategy depends on the input mode (dedicated, ↓
┆19┆┆89┆┄┄general), which is indicated by the user at call establishment ↓
┆19┆┆89┆┄┄(see ref. (3)).↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ┆a1┆dedicated:↲
↲
╞ An RR packet is sent if↲
╞ 1) ┆84┆the window is closed and one or more input buffers are ↓
┆19┆┆8f┆┄┄awailable, and no output data is queued in the dte_chan pro┄↓
┆19┆┆8f┆┄┄cess.↲
╞ 2) ┆84┆expiration of either the idle timer or the ack timer (expla┄↓
┆19┆┆8f┆┄┄nation of these timers see below).↲
↲
╞ ┆a1┆┆b0┆general:↲
↲
╞ ┆84┆An RR packet is sent as quickly as possible. It is the same stra┄↓
┆19┆┆89┆┄┄tegy as for dedicated with the exception that the input buffer li┄↓
┆19┆┆89┆┄┄mitation is not used.↲
↲
╞ ┆84┆With the fact in mind that rdataqueue = w_recv+1 in case of general input ↓
┆19┆┆89┆┄┄and that piggy backing of acknowledgement is possible the follow┄↓
┆19┆┆89┆┄┄ing flowchart decribes the acknowledgement strategy.↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ a: send window open ((nsps-slw) mod 8 < w_xmit)↲
╞ b: possible to move receive window (rdataqueue > 0)↲
╞ c: receive window closed (lrps = (rlw + w_recv) mod 8)↲
↲
╞ Figure 41: Acknowledgement strategy flowchart.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆The two timers mentioned in this subsection are:↲
↲
╞ ┆b0┆idle timer ┆f0┆┆b0┆: ┆84┆┆f0┆this timer is defined in order to avoid long pe┄↓
┆19┆┆9a┆┆82┆┄riods with no traffic and the following dead ↓
┆19┆┆9a┆┆82┆┄lock situation.↲
↲
╞ ╞ ╞ ┆b0┆DCE╞ ╞ DTE↲
╞ ╞ ╞ data(4)↲
↲
╞ ╞ ╞ ╞ data(5)↲
╞ ╞ send window↲
╞ ╞ ┆81┆closed↲
╞ ╞ ╞ ╞ RR(6)↲
↲
↲
╞ ┆b0┆ack timer :┆f0┆ ┆84┆this timer is defined in order to optimize the ↓
┆19┆┆9a┆┆81┆┄use of piggy backing:↲
╞ ╞ ┆84┆If no data to send, then wait a very short time ↓
┆19┆┆9a┆┄┄(possible zero) before sending RR to see, if the ↓
┆19┆┆9a┆┄┄user allready has delivered output data to the ↓
┆19┆┆9a┆┄┄DTE.↲
↲
╞ The default values of the timers are↲
↲
╞ idle timer : 30 secs.↲
╞ ack timer : 1 sec.↲
↲
╞ ┆84┆These may be changed in the dte process using an LCP operation ↓
┆19┆┆89┆┄┄(DTE 54,0) (see ref. (4)) and are delivered to the dte_chan pro┄↓
┆19┆┆89┆┄┄cess at call establishment in the ┆b0┆sync_mess┆f0┆ (subsection 3.2.5.1).↲
↲
↲
┆a1┆4.6.9╞ Maintenance of Output Data Sequence.↲
↲
╞ ┆84┆The dte_chan process returns output data from a user in the same ↓
┆19┆┆89┆┄┄sequence as received. To support this feature a variable ↓
┆19┆┆89┆┄┄(not_ack_data) of type not_ack_type is defined. Furthermore output ↓
┆19┆┆89┆┄┄data are first returned at the time, when they are acknowledged by ↓
┆19┆┆89┆┄┄the DCE.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ not_ack_type = record↲
╞ buf_ref╞ : reference;↲
╞ ╞ not_returned,↲
╞ ╞ level3_ack : boolean;↲
╞ ╞ end;↲
↲
╞ not_ack_data = array (0..7) of not_ack_type;↲
↲
╞ next_ack_buf : byte;↲
↲
╞ ┆84┆next_ack_buf points to the next buffer to be returned to the user.↲
↲
╞ ┆84┆When an user output data is sent to the HDLC for transmission the ↓
┆19┆┆89┆┄┄u3 field in the user buffer is set to the P(S) value of the packet ↓
┆19┆┆89┆┄┄and this number is furthermore used as index in not_ack_data. At ↓
┆19┆┆89┆┄┄the same time not_returned is set to true and level3_ack to false.↲
↲
╞ ┆84┆When an output message is returned from the HDLC not_returned is ↓
┆19┆┆89┆┄┄set to false and the buffer is 'hanged' on the reference buf_ref. ↓
┆19┆┆89┆┄┄Then all preciding buffers from next_ack_buf up to the first where ↓
┆19┆┆89┆┄┄not_returned = true or level3_ack = false are returned to the ↓
┆19┆┆89┆┄┄user, and at last next_ack_buf is moved.↲
↲
╞ ┆84┆When a packet is acknowledged by the DCE, level3_ack is set to ↓
┆19┆┆89┆┄┄true, and all preciding buffers from next_ack_buf up to the first ↓
┆19┆┆89┆┄┄where not_returned = true or level3_ack = false are returned to ↓
┆19┆┆89┆┄┄the user, and at last next_ack_buf is moved.↲
════════════════════════════════════════════════════════════════════════
↓
«index» formatlinie til RC manualer↲
┆14┆┆b3┆↲
┆14┆┆b3┆┆06┆- ┆0b┆ -↲
┆a1┆5.╞ ERROR MESSAGES.↲
↲
╞ ┆84┆The DTE System procedures error messages in several cases.↲
↲
╞ ┆84┆Most of the error messages mean that one of the surrounding mo┄↓
┆19┆┆89┆┄┄dules has reacted in an unexpected way or the programmer has sup┄↓
┆19┆┆89┆┄┄plied the module with wrong default parameter values.↲
↲
╞ ┆84┆In other situations the module will exit through the PANIC subrou┄↓
┆19┆┆89┆┄┄tine, and the programmer must then check up the source programs ↓
┆19┆┆89┆┄┄for internal errors.↲
↲
╞ ┆84┆In both cases some of the errors are fatal (exit of process incar┄↓
┆19┆┆89┆┄┄nation) and others are only warnings.↲
↲
╞ ┆84┆As already mentioned in subsection 4.1.2.4 the DTE System uses two ↓
┆19┆┆89┆┄┄procedures for error information, ┆b0┆error_text┆f0┆ for writing in natu┄↓
┆19┆┆89┆┆81┆┄ral text and ┆b0┆error_report┆f0┆ for numeric information only.↲
↲
╞ ┆84┆In the following two sections the error messages from the indi┄vi┄↓
┆19┆┆89┆┄┄dual processes will be outlined.↲
↲
↲
┆a1┆5.1╞ Error Messages from error_text.↲
↲
╞ ┆84┆In this section error messages procedures by using ┆b0┆error_text ┆f0┆is ↓
┆19┆┆89┆┆81┆┄described.↲
╞ The format of the description is:↲
↲
╞ - error text↲
╞ - explanation↲
╞ - fatal/warning, process name.↲
↲
╞ The messages are arranged in alfabetic order.↲
↲
↲
┆b0┆╞ ****╞ ┆84┆call from DTE ACC not stacked↲
╞ ╞ ┆84┆A ┆b0┆chan_start ┆f0┆message from dte_access is not stacked with ↓
┆19┆┆93┆┆81┆┄a user request message.↲
╞ ╞ Fatal, dte.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆b0┆╞ ****╞ CHAN exception in <incarnation name>↲
╞ followed by either↲
╞ ┆b0┆****╞ ┆84┆CHAN exception in chan process state = idle/exit: ↓
┆19┆┆93┆┆81┆┆82┆<state>↲
╞ ╞ or↲
┆b0┆╞ ****╞ CHAN exception, VC cleared, lcn = <no>↲
┆b0┆╞ ****╞ CHAN vers: <no1>↲
╞ ╞ ┆84┆An exception in a dte_chan process incarnation has oc┄↓
┆19┆┆93┆┄┄cured. If the first case is printed, the exception has ↓
┆19┆┆93┆┄┄occured in the state idle (<state>=1) or exit (<state> ↓
┆19┆┆93┆┄┄=0). In the second case, the Virtual Call with logical ↓
┆19┆┆93┆┄┄channel num┄ber <no> is cleared. <no1> is the version ↓
┆19┆┆93┆┄┄number of the dte_chan process.↲
╞ ╞ Warning, dte.↲
↲
┆b0┆╞ ****╞ create <name> not possible: <no>↲
╞ ╞ ┆84┆It was not possible to create an incarnation of the ↓
┆19┆┆93┆┄┄<name> process.↲
╞ ╞ ┆84┆<no> is the result from the call of create (see ref. ↓
┆19┆┆93┆┄┄(13)).↲
↲
╞ ╞ <name> are:↲
╞ ╞ DTE ACC╞ fatal, dte↲
╞ ╞ DTE CHAN╞ fatal, dte↲
╞ ╞ DTE CLOCK╞ fatal, dtetest↲
╞ ╞ DTE HREC╞ fatal, dte↲
╞ ╞ DTE LCN0╞ fatal, dte↲
╞ ╞ DTE POOLH╞ fatal, dte↲
╞ ╞ DTE TEST╞ warning, dte↲
╞ ╞ DTE SNOOP╞ warning, dte↲
╞ ╞ OUTTRACE╞ warning, dte↲
╞ ╞ TRACE╞ ╞ warning, dte↲
╞ ╞ Fatal/warning, dte/dtetest↲
↲
╞ ┆b0┆****╞ default LTCN greater than default HTCN↲
╞ ╞ ┆84┆The default assigned interval limits are not pos┄sible. ↓
┆19┆┆93┆┄┄Lower number greater than higher.↲
╞ ╞ Fatal, dte.↲
↲
┆8c┆┄┆a7┆↓
┆b0┆****╞ default window size out of range : <no>╞ ↲
╞ ╞ ┆84┆The default window size is greater than 7. <no> is the ↓
┆19┆┆93┆┄┄value of dte_conf_rec.dw_size.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ diagnostic packet not allowed↲
╞ ╞ ┆84┆The procedure ┆b0┆dec_x25 ┆b0┆┆f0┆(see subsection 4.1.2.1) gives the ↓
┆19┆┆93┆┆82┆┄result 'diag_not_allw'. Error in procedure, if module is ↓
┆19┆┆93┆┆82┆┄used as DTE.↲
╞ ╞ Warning, dte_lcnzero.↲
↲
┆b0┆╞ ****╞ DTE disconnected from NCP↲
╞ ╞ Warning, dte.↲
↲
┆b0┆╞ ****╞ DTE received HDLC exception/parity error↲
┆b0┆╞ ****╞ DTE gives up to connect DRIVER↲
╞ ╞ ┆84┆The DTE has received an event indicating an HDLCLCP ex┄↓
┆19┆┆93┆┄┄ception or an parity error in the controller.↲
╞ ╞ Warning, dte.↲
↲
┆b0┆╞ ****╞ error in default HTC, LTC : <no>↲
╞ ╞ ┆84┆The default assigned interval (ltc, htc) is greater than ↓
┆19┆┆93┆┄┄dte_conf_rec.max_chan. <no> = htc-ltc+1.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ error in own DTE ADDRESS at index = <no>↲
╞ ╞ ┆84┆The digit at index <no> is not within the range 0..9.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ error in request_event_buf from NCP : <no>↲
╞ ╞ ┆84┆A ┆b0┆request_event_buf ┆f0┆message is returned from the NCP ↓
┆19┆┆93┆┆81┆┄with an unexpected u2 value (<no>).↲
╞ ╞ Warning, dte.↲
↲
┆b0┆╞ ****╞ exception received from unknown process↲
╞ ╞ ┆84┆A ┆b0┆break ┆f0┆message is received from an unknown process.↲
╞ ╞ Warning, dte.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ****╞ HDLC control operation returned with user term↲
┆b0┆╞ ****╞ DTE gives up to connect DRIVER↲
╞ ╞ ┆84┆An HDLC control operation is returned with an result in┄↓
┆19┆┆93┆┄┄dicating either HDLCLCP exception or controller parity ↓
┆19┆┆93┆┄┄error.↲
╞ ╞ Warning, dte.↲
↲
┆b0┆╞ ****╞ illegal channel↲
╞ ╞ ┆84┆The procedure ┆b0┆dec_x25 ┆f0┆(see subsection 4.1.2.1) gives the ↓
┆19┆┆93┆┆81┆┄result 'ill_channel'. I.e. logical channel number is not ↓
┆19┆┆93┆┆81┆┄zero.↲
╞ ╞ Warning, dte_lcnzero.↲
↲
┆b0┆╞ ****╞ illegal HDLC connect ident : <no>↲
╞ ╞ ┆84┆The default parameter hdlc_param.c_id has a negative va┄↓
┆19┆┆93┆┄┄lue (<no>).↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ illegal HDLC retransmission counter : <no>↲
╞ ╞ ┆84┆The default parameter hdlc_param.n2 is out of range (┆a1┆<┆e1┆0 ↓
┆19┆┆93┆┄┄or ┆a1┆>┆e1┆64). <no> is the actual value.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ illegal HDLC retransmission timer : <no>↲
╞ ╞ ┆84┆The default parameter hdlc_param.t1 has a negative value ↓
┆19┆┆93┆┄┄(<no>).↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ illegal operation from sup : <no>↲
╞ ╞ ┆84┆An unknown operation, <no>, is received from the dte ↓
┆19┆┆93┆┄┄process.↲
╞ ╞ Warning, dte_lcnzero.↲
↲
┆b0┆╞ ****╞ illegal state in channel proc desc↲
╞ ╞ ┆84┆A ┆b0┆sync_mess ┆f0┆is received in an illegal state (p_idle, ↓
┆19┆┆93┆┆81┆┄p_exit).↲
╞ ╞ Fatal, dte.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ****╞ illegal value of outstanding HDLC frames : <no>↲
╞ ╞ ┆84┆The default parameter hdlc_param.k equals zero (<no> = ↓
┆19┆┆93┆┄┄0).↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ inc. of Head-pool not possible : <no>↲
╞ ╞ ┆84┆It was not possible to increment the number of buffers ↓
┆19┆┆93┆┄┄in head_pool. <no> indicates the number of buffers, ↓
┆19┆┆93┆┄┄which the pool already is initialized with.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ inc. of Smess-pool not possible : <no>↲
╞ ╞ ┆84┆It was not possible to increment the number of buffers ↓
┆19┆┆93┆┄┄in supmesspool. <no> is the number of buffers, which ↓
┆19┆┆93┆┄┄the pool already is initialized with.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ init of Big-pool not possible : <no>↲
╞ ╞ ┆84┆Initialization of bigpool (big input buffers see subsec┄↓
┆19┆┆93┆┄┄tion 4.1.3) with the required number of buffers is not ↓
┆19┆┆93┆┄┄pos┄sible. <no> is the number of buffers from initpool.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ init of Chres-pool not possible : <no>↲
╞ ╞ ┆84┆Initialization of ch_res_pool (channel restart messages) ↓
┆19┆┆93┆┄┄with dte_conf_rec.max_chan buffers not possible. <no> is ↓
┆19┆┆93┆┄┄the number of buffers from initpool.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ init of Event-pool not possible : <no>↲
╞ ╞ ┆84┆Initialization of event_pool (own internal event buf┄↓
┆19┆┆93┆┄┄fers) with pool_conf_rec.eventbuf_no number of buffers ↓
┆19┆┆93┆┄┄is not possible. <no> is the number of buffers from ↓
┆19┆┆93┆┄┄initpool.↲
╞ ╞ Fatal, dte.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ****╞ init of HDLC event not possible : <no>↲
╞ ╞ ┆84┆Initialization of hdlc_ev_pool (hdlc event pool) with ↓
┆19┆┆93┆┄┄pool_conf_rec.hdlc_eventno number of buffers is not ↓
┆19┆┆93┆┄┄possible. <no> is the number of buffers from initpool.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ init of ┆a1┆┆e1┆H┆e1┆eader-pool not possible : <no>↲
╞ ╞ ┆84┆Initialization of head_pool with the required number of ↓
┆19┆┆93┆┄┄buffers is not possible. <no> is the required number, ↓
┆19┆┆93┆┄┄pool_conf_rec.suphead_no.↲
╞ ╞ Fatal, dte.↲
↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
┆b0┆╞ ****╞ init of Small-pool not possible : <no>↲
╞ ╞ ┆84┆Initialization of smallpool (small input buffers see ↓
┆19┆┆93┆┄┄sub┄section 4.1.3) with the required numbers of buffers ↓
┆19┆┆93┆┄┄is not possible. <no> is the number of buffers from ↓
┆19┆┆93┆┄┄init┄pool.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ init of Smess-pool not possible : <no>↲
╞ ╞ ┆84┆Initialization of supmesspool with the required number ↓
┆19┆┆93┆┄┄of buffers is not possible. <no> is the required number, ↓
┆19┆┆93┆┄┄pool_conf_rec.supmess_no.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ init of Sync-pool not possible : <no>↲
╞ ╞ ┆84┆Initialization of sync_pool with dte_conf_rec.max_chan ↓
┆19┆┆93┆┄┄buffers not possible. <no> is the number of buffers from ↓
┆19┆┆93┆┄┄initpool.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ init of X.25-pool not possible : <no>↲
╞ ╞ ┆84┆Initialization of x25pool (X.25 control output buffers ↓
┆19┆┆93┆┄┄see subsection 4.1.3) with the required number of buf┄↓
┆19┆┆93┆┄┄fers is not possible. <no> is the number of buffers from ↓
┆19┆┆93┆┄┄in┄itpool.↲
╞ ╞ Fatal, dte.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ****╞ link of <name> not possible : <no>↲
╞ ╞ ┆84┆It was not possible to link the <name> process. <no> is ↓
┆19┆┆93┆┄┄the result from the call of link.↲
↲
╞ ╞ <name> are:↲
╞ ╞ DTE ACC╞ fatal↲
╞ ╞ DTE CHAN╞ fatal↲
╞ ╞ DTE HREC fatal↲
╞ ╞ DTE LCN0╞ fatal↲
╞ ╞ DTE POOLH fatal↲
╞ ╞ DTE SNOOP╞ warning↲
╞ ╞ DTE TEST╞ warning↲
╞ ╞ OUTTRACE╞ warning↲
╞ ╞ TRACE╞ warning↲
╞ ╞ Fatal/warning, dte.↲
↲
┆b0┆╞ ****╞ local user address length greater than max_u_adr: <no>↲
╞ ╞ ┆84┆Max_u_adr = 5. <no> is the value of dte_conf_rec.u┄↓
┆19┆┆93┆┄┄ser_length.↲
╞ ╞ Fatal, dte.↲
↲
╞ ┆b0┆****╞ local user address length negative: <no>↲
╞ ╞ ┆84┆The user address may not be negative. <no> is the actual ↓
┆19┆┆93┆┄┄value.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ ┆84┆max chan to big. Recompile with new value of m_max_chan. ↓
┆19┆┆93┆┆81┆┆82┆┆b0┆Cur = <no>↲
╞ ╞ ┆84┆The default parameter dte_conf_rec.max_chan greater than ↓
┆19┆┆93┆┄┄the maximum number of channels (m_max_chan). <no> is the ↓
┆19┆┆93┆┄┄current value of m_max_chan.↲
╞ ╞ Fatal, dte.↲
↲
╞ ┆b0┆****╞ max window size: <mw>↲
╞ ╞ ┆b0┆smaller than default window size: <dw>↲
╞ ╞ ┆84┆The indicated max window size is to small, <mw> and <dw> ↓
┆19┆┆93┆┄┄are the actual values.↲
╞ ╞ Fatal, dte.↲
↲
┆8c┆┄┆a7┆↓
╞ ┆b0┆****╞ max window size to big: <mw>↲
╞ ╞ ┆84┆Max window size greater than 7, <mw> is the actual ↓
┆19┆┆93┆┄┄value.↲
╞ ╞ Fatal, dte.↲
↲
╞ ┆b0┆****╞ NCP busy, function : <no>↲
╞ ╞ ┆84┆The NCP has returned a message with u2 = 'busy'. <no> is ↓
┆19┆┆93┆┄┄the operation code (u1) of the message.↲
╞ ╞ Warning, dte.↲
↲
┆b0┆╞ ****╞ no HDLC connect buffer.↲
╞ ╞ No buffer in hdlc_pool.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ not all buffers released, remaining : <no>↲
╞ ╞ ┆84┆After removed of the TRACE system, all trace buffers was ↓
┆19┆┆93┆┄┄not released. <no> is the number of missing buffers.↲
╞ ╞ Warning, dte.↲
↲
┆b0┆╞ ****╞ not enough pickups to internal snoop↲
╞ ╞ ┆84┆The default value max_pickups was to small (<max_chan) ↓
┆19┆┆93┆┄┄to perform any internal snoop.↲
╞ ╞ Warning, dte.↲
↲
┆b0┆╞ ****╞ not message in u2 : <no>↲
╞ ╞ ┆84┆A message with u2 <> '7' is received from the dte pro┄↓
┆19┆┆93┆┄┄cess. Actual value is <no>.↲
╞ ╞ Warning, dte_lcnzero.↲
↲
┆b0┆╞ ****╞ not possible to connect to the NCP : <no>↲
╞ ╞ ┆84┆A ┆b0┆connect_lcp ┆f0┆message is returned from the NCP with u2 ↓
┆19┆┆93┆┆81┆┄<> 'ok'. <no> is the returned u2 value.↲
╞ ╞ Warning, dte.↲
↲
╞ ┆b0┆****╞ own address length negative: <no>↲
╞ ╞ ┆84┆Own address length may not be negative, <no> is the ↓
┆19┆┆93┆┄┄actual value.↲
╞ ╞ Fatal, dte.↲
↲
┆8c┆┄┆a7┆↓
┆b0┆╞ ****╞ only snoop of main semaphores↲
╞ ╞ ┆84┆The default value max_pickups (netenv appendix B.1), was ↓
┆19┆┆93┆┄┄too small for snoop of both main- and sync sema┄phores of ↓
┆19┆┆93┆┄┄the dte_chan process incarnations.↲
╞ ╞ Warning, dte.↲
↲
┆b0┆╞ ****╞ state table error. Received mess : <no>↲
╞ ╞ ┆84┆The message received (opcode = <no>) provokes a state ↓
┆19┆┆93┆┄┄table error.↲
╞ ╞ Fatal, dte_lcnzero.↲
↲
╞ ┆b0┆****╞ ┆84┆sum of own address length and user length greater than ↓
┆19┆┆93┆┆81┆┆82┆14↲
╞ ╞ ┆b0┆own address length: <no>↲
╞ ╞ ┆b0┆user length : <no1>↲
╞ ╞ ┆84┆Own dte address length and subaddress length are to big ↓
┆19┆┆93┆┄┄to fit into the defined length dte_addr_length (=14). ↓
┆19┆┆93┆┄┄<no> and <no1> are the actual values.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ supmess pool empty↲
╞ ╞ ┆84┆The supervisor message pool (restart- and diagnostic in┄↓
┆19┆┆93┆┄┄dications) is empty.↲
╞ ╞ Fatal, dte_lcnzero.↲
↲
┆b0┆╞ ****╞ supmess pool only init with : <no>↲
╞ ╞ ┆84┆Initialization error with supmess_pool. <no> is the num┄↓
┆19┆┆93┆┄┄ber of buffers, the pool is initialized with.↲
╞ ╞ Warning, dte_lcnzero.↲
↲
┆b0┆╞ ****╞ unexpected DTE LCN0 result↲
╞ ╞ ┆84┆A ┆b0┆restart_start ┆f0┆message is returned from dte_lcnzero ↓
┆19┆┆93┆┆81┆┄with unexpected u2 value. ┆b0┆This error message is preceded ↓
┆19┆┆93┆┆82┆┆82┆by a print of the message fields.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ unexpected HDLC event result : <no>↲
╞ ╞ ┆84┆An HDLC event buffer is returned with an unexpected u2 ↓
┆19┆┆93┆┄┄value (<no>).↲
╞ ╞ Warning, dte.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ****╞ unexpected HDLC result : <no>↲
╞ ╞ ┆84┆An HDLC driver operation is returned with an unexpected ↓
┆19┆┆93┆┄┄u2 value (<no>).↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ unexpected HDLC result (1,12) on mess : <no>↲
╞ ╞ ┆84┆The HDLC operation <no> is returned with either result 1 ↓
┆19┆┆93┆┄┄(driver temporary removed) or 12 (line speed measure┄↓
┆19┆┆93┆┄┄ment).↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ unexpected HDLC result (8) on mess : <no>↲
╞ ╞ ┆84┆The HDLC operation <no> is returned with result 8 (line ↓
┆19┆┆93┆┄┄allready connected).↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ unexpected NCP result↲
╞ ╞ ┆84┆An NCP operation is returned with an unexpected u2 val┄↓
┆19┆┆93┆┄┄ue. ┆b0┆This error message is preceded by a print of the ↓
┆19┆┆93┆┆81┆┆82┆message fields.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ unexpected result in sup message↲
╞ ╞ ┆84┆A dte (supervisor) message is received with an unexpec┄↓
┆19┆┆93┆┄┄ted result. ┆b0┆This error message is preceded by a print of ↓
┆19┆┆93┆┆81┆┆82┆the message fields.↲
╞ ╞ Warning, dte.↲
↲
┆b0┆╞ ****╞ unexpected sup result : <no>↲
╞ ╞ ┆84┆A dte_lcnzero message is returned with an unexpected u2 ↓
┆19┆┆93┆┄┄value (<no>).↲
╞ ╞ Fatal, dte_lcnzero.↲
↲
┆b0┆╞ ****╞ unexpected TIMER result : <no>↲
╞ ╞ ┆84┆A timer request is returned with an unexpected u2 value ↓
┆19┆┆93┆┄┄(<no>).↲
╞ ╞ Fatal, dte_lcnzero.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ****╞ unexpected u3 value in p_active : <no>↲
╞ ╞ ┆84┆A ┆b0┆sync_mess ┆f0┆is received with an unexpected u3 value ↓
┆19┆┆93┆┆81┆┄(<no>) in state p_active.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ unexpected u3 value in p_restart : <no>↲
╞ ╞ ┆84┆A ┆b0┆sync_mess ┆f0┆is received with an unexpected u3 value ↓
┆19┆┆93┆┆81┆┄(<no>) in state p_restart.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ unexpected u3 value in p_stopping : <no>↲
╞ ╞ ┆84┆A ┆b0┆sync_mess ┆f0┆is received with an unexpected u3 value ↓
┆19┆┆93┆┆81┆┄(<no>) in state p_stopping.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ unknown message from DTE┆a1┆┆e1┆_LCN0↲
╞ ╞ ┆84┆A message with an unknown operation code (u1 value) is ↓
┆19┆┆93┆┄┄received from the dte_lcnzero process. ┆b0┆This error messa┄↓
┆19┆┆93┆┆81┆┆82┆ge is preceded by a print of the message fields.↲
╞ ╞ Warning, dte.↲
↲
┆b0┆╞ ****╞ unknown process id↲
╞ ╞ ┆84┆A message is received with an unknown u4 value. ┆b0┆This ↓
┆19┆┆93┆┆81┆┆82┆error message is preceded by a print of the message ↓
┆19┆┆93┆┆81┆┆82┆fields.↲
╞ ╞ Warning, dte/dte_lcnzero.↲
↲
┆b0┆╞ ****╞ X.25 data packet length negative : <no>↲
╞ ╞ ┆84┆<no> is the value of dte_conf_rec.x25_datasize.↲
╞ ╞ Fatal, dte.↲
↲
┆b0┆╞ ****╞ ┆84┆X.25 trace stopped caused by exception incarnation ↓
┆19┆┆93┆┆81┆┆82┆<name>↲
╞ ╞ ┆b0┆DTETRACE version: <no>↲
╞ ╞ ┆84┆┆84┆An exception in a dtetrace process (version <no>) has ↓
┆19┆┆93┆┄┄occured. The TRACE system is removed.↲
╞ ╞ Warning, dte.↲
↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ****╞ WARNING: HDLC driver and internal state error : <no>↲
╞ ╞ ┆84┆The line state in the HDLC driver and internal in the ↓
┆19┆┆93┆┄┄DTE does not correspond. <no> is the value of the inter┄↓
┆19┆┆93┆┄┄nal line state.↲
╞ ╞ Warning, dte.↲
↲
↲
┆a1┆5.2╞ Error Messages from error_report and trace.↲
↲
╞ ┆84┆In case ┆b0┆error_report ┆f0┆is used to produce error messages the struc┄↓
┆19┆┆89┆┆81┆┄ture of a message is↲
↲
┆b0┆╞ trace╞ ╞ excode = AABB╞ called from error_report↲
╞ maybe followed by↲
┆b0┆╞ trace╞ ╞ excode = 00u1╞ called from error_report↲
┆b0┆╞ trace╞ ╞ excode = 00u2╞ called from error_report↲
┆b0┆╞ trace╞ ╞ excode = 00u3╞ called from error_report↲
┆b0┆╞ trace ╞ ╞ excode = 00u4╞ called from error_report↲
╞ and maybe at last↲
┆b0┆╞ trace ╞ ╞ excode = 0001╞ called from panic↲
↲
╞ The values of the excode's are↲
╞ AA = process version number↲
╞ BB = different information↲
╞ u1 = u1 value of a possible message↲
╞ u2 = u2 value of a possible message↲
╞ u3 = u3 value of a possible message↲
╞ u4 = u4 value of a possible message↲
↲
╞ ┆84┆The second to fifth trace do only appear, if a message is invol┄↓
┆19┆┆89┆┄┄ved in the error and the last trace is only to provoke a process ↓
┆19┆┆89┆┄┄exit (exception).↲
↲
╞ ┆84┆The interpretation of the traces is not simple. It requires an ↓
┆19┆┆89┆┄┄source listning, because no number is given to the individual er┄↓
┆19┆┆89┆┄┄rors.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆This print procedure is followed in the processes:↲
╞ dte_access, dte_chan, dte_hrec and dte_lcnzero.↲
↲
╞ ┆84┆If a trace with excode = 00FF occures it is an indication of, that ↓
┆19┆┆89┆┄┄in the exception procedure (in dte, dte_chan, dte_lcnzero) no in┄↓
┆19┆┆89┆┄┄ternal testbuffer was empty, so no copy of the internal testarea ↓
┆19┆┆89┆┄┄is performed.↲
↲
════════════════════════════════════════════════════════════════════════
↓
«index» formatlinie til RC manualer↲
┆14┆┆b3┆↲
┆14┆┆b3┆┆06┆- ┆0b┆ -↲
┆a1┆6.╞ TRACE AND DEBUG TOOLS.↲
↲
╞ ┆84┆At runtime several possibilities exists to see what is happening ↓
┆19┆┆89┆┄┄either inside the DTE System or on the communication line.↲
↲
╞ ┆84┆dtetrace (section 6.1) is used to trace the X.25 level 3 communi┄↓
┆19┆┆89┆┄┄cation on the console, dtetest (section 6.2) is used to control ↓
┆19┆┆89┆┄┄internal test of 3 processes (dte, dte_lcnzero, and dte_chanxxx), ↓
┆19┆┆89┆┄┄and generation of dte_access test messages, and some messages on ↓
┆19┆┆89┆┄┄the console, and dtesnoop (section 6.3) is used to snoop messages ↓
┆19┆┆89┆┄┄received at the main and synchronization semaphores of the ↓
┆19┆┆89┆┄┄dte_chan process.↲
↲
╞ ┆84┆This three systems are ┆b0┆not mandatory┆f0┆ for normal run of the DTE mo┄↓
┆19┆┆89┆┆81┆┄dule. They can be outmitted at link time (see subsection 7.3.2).↲
↲
↲
┆a1┆6.1╞ Trace System.↲
↲
╞ ┆84┆As mentioned above the trace system is used to print the X.25 ↓
┆19┆┆89┆┄┄level 3 communication on the console. The system consists of 2 ↓
┆19┆┆89┆┄┄processes (dtetrace and outtrace), three external procedures ↓
┆19┆┆89┆┄┄(init_trace, end_trace, and tracing) and a buffer pool (trace_buf) ↓
┆19┆┆89┆┄┄of the type specified in subsection 4.1.3.↲
↲
╞ ┆84┆In the following four subsections an overview and a short descrip┄↓
┆19┆┆89┆┄┄tion of the system are given. Furthermore the output on the con┄↓
┆19┆┆89┆┄┄sole is explained.↲
↲
↲
┆a1┆6.1.1╞ Process Overview and Operation.↲
↲
╞ ┆84┆In figure 42 the trace messages flow are outlined together with an ↓
┆19┆┆89┆┄┄indication of where the X.25 level 3 communication are traced ↓
┆19┆┆89┆┄┄(i.e. in which processes the in-/output buffers are copied.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 42: Message flow in the trace system.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆As indicated in figure 42 the output flow are traced in the pro┄↓
┆19┆┆89┆┄┄cess outtrace and the input flow in dte_hrec.↲
↲
╞ ┆84┆The trace system may be in three states:↲
↲
╞ 1) removed↲
╞ 2) created and not active↲
╞ 3) created and active.↲
↲
┆84┆╞ ┆84┆Only in the last state the copy of data buffers will be performed, ↓
┆19┆┆89┆┄┄and only in the last two states the data flow will pass through ↓
┆19┆┆89┆┄┄the process outtrace.↲
↲
╞ ┆84┆The states of the system can be changed dynamicly using an LCP ↓
┆19┆┆89┆┄┄operation (DTE 53,0). The state is indicated using two boolean va┄↓
┆19┆┆89┆┄┄riables (in process dte).↲
↲
╞ _____________________________________________________↲
╞ ! trace_run ! ┆82┆false┆81┆ ! ┆82┆true┆81┆ !↲
╞ ! ! ! !↲
╞ ┆a1┆! trace_on ! ! !↲
! ┆82┆false┆81┆ ! ┆82┆removed┆81┆ ! created and !↲
╞ ┆a1┆!┆a1┆ ! ! not active !↲
╞ ! ┆82┆true┆81┆ ! ! created and !↲
╞ ┆a1┆! ! ! active !↲
↲
╞ Table 8: State variables of the trace system.↲
↲
╞ ┆84┆Whenever the variable trace_on changes from false to true or oppo┄↓
┆19┆┆89┆┄┄site, it is indicated on the console (format and text please see ↓
┆19┆┆89┆┄┄subsection 6.1.4) using the external procedures ┆b0┆init_trace┆f0┆ and ↓
┆19┆┆89┆┆81┆┄┆b0┆end_trace┆f0┆. The copying process of data in-/output is performed us┄↓
┆19┆┆89┆┆82┆┄ing the external procedure ┆b0┆tracing┆f0┆. All three procedures are exp┄↓
┆19┆┆89┆┆83┆┄lained in subsection 4.1.2.5.↲
↲
╞ ┆84┆Whenever a trace buffer is outfilled (either by ┆b0┆init_trace, ↓
┆19┆┆89┆┆81┆┆82┆end_trace┆f0┆ or ┆b0┆tracing┆f0┆) it is returned (in the procedure) to the ↓
┆19┆┆89┆┆82┆┄main semaphore of the dtetrace process.↲
↲
┆8c┆┄┆a7┆↓
╞ ┆84┆In the dtetrace process the data are time stamped and formatted ↓
┆19┆┆89┆┄┄according to a standard format and operator defined parameters ↓
┆19┆┆89┆┄┄(subsection 6.1.3), put in a standard zone output buffer and this ↓
┆19┆┆89┆┄┄buffer is signalled to the operator process. The trace buffer is ↓
┆19┆┆89┆┄┄then returned to the common pool trace_buf.↲
↲
╞ ┆84┆The two processed constituting the trace system has the following ↓
┆19┆┆89┆┄┄process heads.↲
↲
╞ ┆b0┆PROCESS dte_trace (↲
╞ opsem╞ : sempointer;↲
╞ VAR trace_ptr : ! tap_pointer;↲
╞ VAR trace_buf : ph_type;↲
╞ VAR break_sem : semaphore;↲
╞ console_out : boolean↲
╞ );↲
↲
┆b0┆╞ PROCESS out_trace (↲
╞ VAR in_ptr : ! tap_pointer;↲
╞ VAR hdlc_sem : ! sempointer;↲
╞ VAR trace_buf : ph_type;↲
╞ VAR trace_on : ! boolean↲
╞ );↲
↲
╞ opsem╞ ╞ : ┆84┆Pointer to the main semaphore of the opera┄↓
┆19┆┆9f┆┄┄tor process.↲
↲
╞ trace_ptr╞ ╞ : ┆84┆Main semaphore pointer of the dtetrace pro┄↓
┆19┆┆9f┆┄┄cess.↲
↲
╞ trace_buf╞ ╞ : Trace buffer pool.↲
↲
╞ break_sem╞ ╞ : ┆84┆Semaphore holding the break message used in ↓
┆19┆┆9f┆┄┄the exception procedure.↲
↲
╞ console_out╞ : ┆84┆If true the version id is printed on the ↓
┆19┆┆9f┆┄┄console at process start↲
↲
╞ in_ptr╞ ╞ : ┆84┆Main semaphore pointer of the outtrace pro┄↓
┆19┆┆9f┆┄┄cess.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ hdlc_sem╞ ╞ : Semaphore pointer to the HDLCLCP.↲
↲
╞ trace_on╞ ╞ : ┆84┆Boolean indicating whether the X.25 packet ↓
┆19┆┆9f┆┄┄flow shall be traced (true) or not (false). ↓
┆19┆┆9f┆┄┄Changed dynamicly by the dte process.↲
↲
↲
┆a1┆6.1.2╞ External Communication.↲
↲
╞ ┆84┆For operator communication standard RTP input/output zones (ref. ↓
┆19┆┆89┆┄┄(15)) are used. The format of a trace buffer is described below. A ↓
┆19┆┆89┆┄┄trace buffer is only generated in one of the tracing procedures ↓
┆19┆┆89┆┄┄(subsection 4.1.2.5).↲
↲
╞ ┆a1┆┆b0┆Message name┆e1┆: timeread↲
↲
╞ ┆a1┆Message format┆e1┆:↲
╞ ╞ message sent╞ ╞ answer recv.↲
╞ u1╞ ╞ 1╞ ╞ unch↲
╞ u2╞ ╞ 7╞ ╞ 0↲
╞ u3╞ ╞ -╞ ╞ 0↲
╞ u4╞ ╞ -╞ ╞ unch↲
↲
╞ buf╞ ╞ -╞ ╞ delaytype↲
↲
╞ delaytype is defined in the standard environment.↲
↲
╞ ┆a1┆Function┆e1┆:↲
↲
╞ ┆84┆The dtetrace process requests the timer process to return the cur┄↓
┆19┆┆89┆┄┄rent time and date. These are used to time stamp the console out┄↓
┆19┆┆89┆┄┄put.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ┆a1┆Message name┆e1┆: trace_init↲
↲
╞ ┆a1┆Message format┆e1┆:↲
╞ ╞ message recv.↲
╞ u1╞ ╞ 2↲
╞ u2╞ ╞ -↲
╞ u3╞ ╞ -↲
╞ u4╞ ╞ -↲
↲
╞ buf╞ ╞ -↲
↲
╞ ┆a1┆Function┆e1┆:↲
↲
╞ ┆84┆The message indicates, that the level 3 trace has been started. ↓
┆19┆┆89┆┄┄Start identification (see subsection 6.1.4) including date and ↓
┆19┆┆89┆┄┄time is printed on the console.↲
↲
┆b0┆╞ ┆a1┆Message name┆e1┆: trace_end↲
↲
╞ ┆a1┆Message format┆e1┆:↲
╞ ╞ message recv.↲
╞ u1╞ ╞ 4↲
╞ u2╞ ╞ -↲
╞ u3╞ ╞ -↲
╞ u4╞ ╞ -↲
↲
╞ buf╞ ╞ -↲
↲
╞ ┆a1┆Function┆e1┆:↲
↲
╞ ┆84┆The message indicates, that the level 3 trace has been stopped. ↓
┆19┆┆89┆┄┄Stop identification (see subsection 6.1.4) including date and time ↓
┆19┆┆89┆┄┄is printed on the console.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ┆a1┆Message name┆e1┆: trace_data↲
↲
╞ ┆a1┆Message format┆e1┆:↲
╞ ╞ message recv.↲
╞ u1╞ ╞ 3↲
╞ u2╞ ╞ -↲
╞ u3╞ direction↲
╞ u4╞ ╞ -↲
↲
╞ buf╞ trace_buf_type↲
↲
╞ trace_buf_type = record↲
╞ ╞ ╞ first, last, next : integer;↲
╞ ╞ ╞ x25_packet : x25_packet_type;↲
╞ ╞ ╞ end;↲
↲
╞ x25_packet_type is the copied X.25 packet.↲
↲
╞ ┆a1┆Function┆e1┆:↲
↲
╞ ┆84┆The received message contains an X.25 packet, which is decoded us┄↓
┆19┆┆89┆┄┄ing the procedure ┆b0┆dec_x25┆f0┆ (see subsection 4.1.2.1). The result ↓
┆19┆┆89┆┆81┆┄from this decoding together with the time and direction (received ↓
┆19┆┆89┆┆81┆┄= 0, sent = 1) is formatted and printed on the console (see sub┄↓
┆19┆┆89┆┆81┆┄section 6.1.4).↲
↲
┆b0┆╞ ┆a1┆Message name┆e1┆: trace_error↲
↲
╞ ┆a1┆Message format┆e1┆:↲
╞ ╞ message recv.↲
╞ u1╞ ╞ 5↲
╞ u2╞ ╞ -↲
╞ u3╞ ╞ -↲
╞ u4╞ error_type↲
↲
╞ buf -↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆a1┆Function┆e1┆:↲
↲
╞ ┆84┆An error in one of the trace procedures has occured. At the moment ↓
┆19┆┆89┆┄┄only one error has been identified (copy error in tracing, ↓
┆19┆┆89┆┄┄error_type = 1). An identification of the error is printed on the ↓
┆19┆┆89┆┄┄console.↲
↲
↲
┆a1┆6.1.3╞ Operator Commands.↲
↲
╞ ┆84┆As mentioned in subsection 6.1.1 the operator can set parameters ↓
┆19┆┆89┆┄┄de┄fining some of the format for the trace output. The following ↓
┆19┆┆89┆┄┄com┄mands are available:↲
↲
┆b0┆╞ data yes no ╞ ┆f0┆: ┆84┆If the option is yes, the user data field of ↓
┆19┆┆9f┆┆81┆┄an X.25 DATA packet is printed on the next ↓
┆19┆┆9f┆┆81┆┄line in either ascii or hexadecimal format. ↓
┆19┆┆9f┆┆81┆┄If the option is no the data is not printed. ↓
┆19┆┆9f┆┆81┆┄┆b0┆Default : no.↲
↲
┆b0┆╞ call yes no╞ ┆f0┆: ┆84┆If the option is yes, the address fields and ↓
┆19┆┆9f┆┆81┆┄facility fields of CALL REQUEST and INCOM┄↓
┆19┆┆9f┆┆81┆┄ING CALL are printed on the next line in ↓
┆19┆┆9f┆┆81┆┄either ascii or hexadecimal format. If the ↓
┆19┆┆9f┆┆81┆┄option is no, no extra fields are printed.↲
╞ ╞ ╞ ┆b0┆Default : no.↲
↲
┆b0┆╞ diag yes no╞ ┆f0┆: ┆84┆If the option is yes, the DIAGNOSTIC expla┄↓
┆19┆┆9f┆┆81┆┄nation field is printed on the next line in ↓
┆19┆┆9f┆┆81┆┄either ascii or hexadecimal format. If the ↓
┆19┆┆9f┆┆81┆┄option is no, the field is not printed.↲
╞ ╞ ╞ ┆b0┆Default : no.↲
↲
┆b0┆╞ hex╞ ╞ ┆f0┆: ┆84┆The print format is changed to hexadecimal. ↓
┆19┆┆9f┆┆81┆┄┆b0┆Default format.↲
↲
╞ ┆b0┆ascii╞ ╞ ┆f0┆: ┆84┆The print format is changed to ascii.↲
╞ ╞ ╞ ┆b0┆Not default format.↲
↲
┆8c┆┄┆a7┆↓
╞ ┆84┆If an error occurs in the commands the dtetrace process answers ↓
┆19┆┆89┆┄┄with:↲
↲
╞ ┆a1┆┆e1┆ ┆b0┆**** WHAT ?↲
↲
↲
┆a1┆6.1.4╞ Traceoutput Description.↲
↲
╞ ┆84┆In this subsection the fields of a trace are explained and in ap┄↓
┆19┆┆89┆┄┄pendix D.1 an example of a trace is shown.↲
↲
╞ ┆84┆When the trace system is activate the following line is printed:↲
↲
╞ ┆a1┆┆e1┆ ┆b0┆*** X.25 trace initialized at <date and time>↲
↲
╞ and at deactivation:↲
↲
╞ ┆a1┆┆e1┆ ┆b0┆*** trace stopped at <date and time>↲
↲
╞ ┆84┆Each line in between these two has the following format:↲
↲
╞ <time>╞ ╞ : Time stamp.↲
↲
╞ recv/send╞ : Direction of flow (input/output).↲
↲
╞ <packet id>╞ : Packet type (e.g. data, rr, reset req).↲
↲
╞ LCN = <no>╞ : Logical channel number.↲
↲
╞ qdm=<no> / -d-=<no> : ┆84┆The values of the q-, d-, and m- bits if ↓
┆19┆┆9f┆┄┄they are included in the packet format.↲
↲
╞ PS = <no>╞ ╞ : ┆84┆Send sequence number if included in the pac┄↓
┆19┆┆9f┆┄┄ket format.↲
↲
╞ PR = <no>╞ ╞ : ┆84┆Acknowledge sequence number (next expected) ↓
┆19┆┆9f┆┄┄if included in the packet format.↲
↲
╞ octet 4 = <no>╞ : If included in the packet format.↲
↲
┆8c┆┄┆a8┆↓
╞ octet 5 = <no>╞ : If included in the packet format.↲
↲
╞ size ╞ ╞ : ┆84┆The length of the packet incl. the X.25 head if ↓
┆19┆┆9f┆┄┄the packet is either a CALL REQUEST, INCOM┄↓
┆19┆┆9f┆┄┄ING CALL, CALL ACCEPTED, CALL CONNECTED, ↓
┆19┆┆9f┆┄┄DIAGNOSTIC or DATA.↲
↲
╞ ┆84┆If the user data field of the packet is printed (see subsection ↓
┆19┆┆89┆┄┄6.1.3) this will occure on the next line.↲
↲
╞ ┆84┆The following error texts may occure in connection with the trace ↓
┆19┆┆89┆┄┄system.↲
↲
╞ ┆a1┆┆e1┆ ┆b0┆ >>>> packet smaller than 3 bytes↲
↲
↲
╞ ┆a1┆┆e1┆ ┆b0┆ >>> packet format error↲
↲
↲
╞ ┆a1┆┆e1┆ ┆b0┆>>> unknown packet type↲
↲
↲
╞ ┆a1┆┆e1┆ ┆b0┆ >>> trace buffer copy error↲
↲
↲
╞ ┆a1┆┆e1┆ ┆b0┆ >>> unknown trace opcode↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆6.2╞ Internal Test System.↲
↲
╞ ┆84┆A possibility exists to generate internal test records in the ↓
┆19┆┆89┆┄┄three dte processes: dte, dte_lnczero, dte_chanxxx, and to 'read' ↓
┆19┆┆89┆┄┄variables in the dte_access process. Furthermore information ↓
┆19┆┆89┆┄┄concerning the status of the communication line may be printed on ↓
┆19┆┆89┆┄┄the console. The link between the DTE Mo┄dule and the console/ope┄↓
┆19┆┆89┆┄┄rator is the dtetest process. To maintain a DTE global timer a ↓
┆19┆┆89┆┄┄dteclock process exists.↲
↲
╞ ┆84┆In the following four subsections an overview and short descrip┄↓
┆19┆┆89┆┄┄tion of the system are given. Furthermore the input from / output ↓
┆19┆┆89┆┄┄to the console are explained. ↲
↲
↲
┆a1┆6.2.1╞ Process Overview and Operation.↲
↲
╞ ┆84┆As mentioned above the dtetest process is the link between the in┄↓
┆19┆┆89┆┄┄ternal test generation and the console. In the three processes ↓
┆19┆┆89┆┄┄dte, dte_lcnzero and dte_chanxxx testrecords are generated in the ↓
┆19┆┆89┆┄┄procedure ┆b0┆otest┆f0┆, (triggered by certant events) and stored in ↓
┆19┆┆89┆┆81┆┄an inter┄nal testarea of each process. Whenever this area is full, ↓
┆19┆┆89┆┆81┆┄the pro┄cess tries to copy it to a testbuffer requested from the ↓
┆19┆┆89┆┆81┆┄test se┄maphore. If it succed the area is cleared otherwise it is ↓
┆19┆┆89┆┆81┆┄used cyclic.↲
↲
╞ ┆84┆The testbuffer is returned to the main semaphore of the dtetest ↓
┆19┆┆89┆┄┄process. This process signals the buffer to the test semaphore if ↓
┆19┆┆89┆┄┄not imme┄diatly print is required. If later on, a print is ↓
┆19┆┆89┆┄┄requested, the dtetest process will search the test semaphore for ↓
┆19┆┆89┆┄┄testbuffers from the required process, format the test records and ↓
┆19┆┆89┆┄┄use a stand┄ard i/o zone to print the testrecords on the console.↲
↲
╞ ┆84┆As can be seen from this the testbuffers are used as a spooling ↓
┆19┆┆89┆┄┄queue with a certant life time. The life time depends on the rate ↓
┆19┆┆89┆┄┄by which testrecords are generated, the number of buffers, and how ↓
┆19┆┆89┆┄┄many processes generating testrecords.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆In figure 43 the testmessage flow is outlined.↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 43: Message flow of testmessages.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆Whether a process shall generate testrecords or not depends on a ↓
┆19┆┆89┆┄┄bit in the testbit record (┆b0┆test┆f0┆). Beside these bits the testbit ↓
┆19┆┆89┆┆81┆┄record contains bits, which value indicate whether version infor┄↓
┆19┆┆89┆┆81┆┄mation and information con┄cerning the status of the com┄mu┄nication ↓
┆19┆┆89┆┆81┆┄line shall be printed or not. The test┄bit record is described ↓
┆19┆┆89┆┆81┆┄below.↲
↲
╞ ┆84┆These last informations are printed directly from the dte process, ↓
┆19┆┆89┆┄┄and at the time the event occurs. The bits controlling the prin┄↓
┆19┆┆89┆┄┄ting cannot be set from the console via the dte┄test process, but ↓
┆19┆┆89┆┄┄can be read.↲
↲
╞ test = packed array (1..8) of boolean;↲
↲
╞ ________________________↲
╞ ┆a1┆┆e1┆ ┆a1┆ 1 2 3 4 5 6 7 8 ↲
╞ ╞ ╞ line event printing↲
╞ ╞ modem signals printing↲
╞ ╞ level 3 restart printing↲
╞ ╞ line state printing↲
╞ ╞ version printing↲
╞ dte_lcnzero test generation↲
╞ dte_chan test generation↲
╞ dte test generation.↲
↲
╞ ┆84┆If a bit is true the actions described will be performed, other┄↓
┆19┆┆89┆┄┄wise nothing.↲
↲
┆b0┆╞ dte test generation╞ ┆f0┆: ┆84┆the dte process will generate in┄↓
┆19┆┆a9┆┆81┆┄ternal testrecords↲
↲
╞ ┆b0┆dte_chan test generation╞ ┆f0┆: ┆84┆the dte_chan incarnations will ge┄↓
┆19┆┆a9┆┆81┆┄nerate internal testrecords↲
↲
┆b0┆╞ dte_lcnzero test generation╞ ┆f0┆: ┆84┆the dte_lcnzero process will gene┄↓
┆19┆┆a9┆┆81┆┄rate internal testrecords↲
↲
┆b0┆╞ version printing┆f0┆╞ ╞ : ┆84┆the dte, dtetest and dtetrace will ↓
┆19┆┆a9┆┆81┆┄print version information on the ↓
┆19┆┆a9┆┆81┆┄console at start time↲
↲
┆8c┆┄┆a9┆↓
╞ ┆b0┆line state printing╞ ╞ ┆f0┆: ┆84┆the internal line state (see sub┄↓
┆19┆┆a9┆┆81┆┄sec┄tion 4.2.2) and the line event ↓
┆19┆┆a9┆┆81┆┄are printed every time an event ↓
┆19┆┆a9┆┆81┆┄buffer is returned from the HDLC↲
↲
┆b0┆╞ level 3 restart printing╞ ┆f0┆: ┆84┆whenever the DTE performs an re┄↓
┆19┆┆a9┆┆81┆┄start, the event causing the re┄↓
┆19┆┆a9┆┆81┆┄start is printed↲
↲
┆b0┆╞ modem signals printing╞ ┆f0┆: ┆84┆if it is not possible to set the ↓
┆19┆┆a9┆┆81┆┄modem signals (subsection 4.1.2.2) ↓
┆19┆┆a9┆┆81┆┄pro┄perly, the value of the signals ↓
┆19┆┆a9┆┆81┆┄are printed↲
↲
┆b0┆╞ line event printing╞ ╞ ┆f0┆: ┆84┆the received line event (from the ↓
┆19┆┆a9┆┆81┆┄HDLC) is printed.↲
↲
╞ ┆84┆All the different texts and formats are outlined in subsection ↓
┆19┆┆89┆┄┄6.2.4.↲
↲
╞ ┆84┆The individual bits in the testbit record can be changed using ↓
┆19┆┆89┆┄┄either an LCP operation (DTE 52,0) or directly from the console. ↓
┆19┆┆89┆┄┄The last possibility only includes bit 1, 2 and 3. The operator ↓
┆19┆┆89┆┄┄commands are explained in subsection 6.2.3.↲
↲
╞ ┆84┆An internal test (e.g. in dte) can be started/stopped by setting ↓
┆19┆┆89┆┄┄the appropriate bit to true/false respectively. This action only ↓
┆19┆┆89┆┄┄starts or stops the ┆a1┆generation┆e1┆ of testrecords, nothing is printed ↓
┆19┆┆89┆┄┄on the console. In order to get the formatted testrecords, the op┄↓
┆19┆┆89┆┄┄erator has to issue the command '┆b0┆print┆f0┆', while the test still is ↓
┆19┆┆89┆┆81┆┄active. This command will starts the printing of the testrecords ↓
┆19┆┆89┆┆81┆┄on the console and will continue until (and include) the next buf┄↓
┆19┆┆89┆┆81┆┄fer of the specified process type is received by the dtetest pro┄↓
┆19┆┆89┆┆81┆┄cess.↲
↲
╞ ┆84┆An other possibility is to set the dtetest process in the mode ↓
┆19┆┆89┆┄┄'┆b0┆running┆f0┆', which means that all received testbuffers are printed ↓
┆19┆┆89┆┆81┆┄immediately.↲
↲
┆8c┆┄┆a7┆↓
╞ ┆84┆Furthermore it is possible to get the current value of the test ↓
┆19┆┆89┆┄┄area copied to a testbuffer immediately using the command ↓
┆19┆┆89┆┄┄'┆b0┆provoke┆f0┆'.↲
↲
╞ ┆84┆The above mentioned commands and their format are explained in ↓
┆19┆┆89┆┄┄subsection 6.2.3.↲
↲
╞ ┆84┆All test records contain a dte global time stamp, i.e. a time only ↓
┆19┆┆89┆┄┄relevant to the processes of the DTE Module. This makes it poss┄↓
┆19┆┆89┆┄┄ible to correlate events happening in different DTE processes. The ↓
┆19┆┆89┆┄┄dteclock process (internal process in dtetest) maintains this ↓
┆19┆┆89┆┄┄'clock' (global_time) by reques┄ting a timer interrupt each 200msec ↓
┆19┆┆89┆┄┄from the TIMER.↲
↲
╞ ┆84┆The process head of the dtetest and dteclock processes are defined as:↲
↲
┆b0┆╞ PROCESS dte_test (↲
╞ VAR mainsem╞ : semaphore;↲
╞ VAR operatorsem : ! sempointer;↲
╞ VAR dte_test_hook,↲
╞ breaksem : semaphore;↲
╞ VAR global_time : integer;↲
╞ VAR test_record : testrectype↲
╞ );↲
↲
╞ ┆b0┆PROCESS dteclock (↲
╞ VAR mainsem : semaphore;↲
╞ VAR global_time : integer↲
╞ );↲
↲
↲
╞ mainsem╞ ╞ : Own main semaphore.↲
↲
╞ operatorsem╞ : ┆84┆Main semaphore pointer of the operator pro┄↓
┆19┆┆9f┆┄┄cess.↲
↲
╞ dte_test_hook╞ : ┆84┆Semaphore used as a DTE global testbuffer ↓
┆19┆┆9f┆┄┄pool (testsem).↲
↲
┆8c┆┄┆a7┆↓
╞ breaksem╞ ╞ : ┆84┆Semaphore holding the break message used in ↓
┆19┆┆9f┆┄┄the exception procedure.↲
↲
╞ global_time╞ : ┆84┆DTE global time used to time stamp testre┄↓
┆19┆┆9f┆┄┄cords.↲
↲
╞ test_record╞ : testbits record.↲
↲
↲
┆a1┆6.2.2╞ External Communication.↲
↲
╞ ┆84┆For operator communication standard RTP input/output zones (ref. ↓
┆19┆┆89┆┄┄(15)) are used. Beside these messages only two type of messages ↓
┆19┆┆89┆┄┄(dte_access test answers and testmessages) are received by the dtetest ↓
┆19┆┆89┆┄┄pro┄cess and one (timer request answers) by the dteclock process.↲
↲
┆b0┆╞ ┆a1┆Message name┆e1┆: timer_mess↲
↲
╞ ┆a1┆Message format┆e1┆:↲
╞ ╞ message sent╞ ╞ answer recv.↲
╞ u1╞ ╞ 5╞ ╞ unch↲
╞ u2╞ 200╞ ╞ result↲
╞ u3╞ ╞ 0╞ ╞ 0↲
╞ u4╞ ╞ -╞ ╞ unch↲
↲
╞ buf╞ ╞ -╞ ╞ -↲
↲
╞ ┆a1┆Function┆e1┆:↲
↲
╞ ┆84┆The dteclock process requests the timer process to return the mes┄↓
┆19┆┆89┆┄┄sage after the time specified : 200 * 2**0 msec = 200 msec.↲
↲
╞ ┆a1┆Result┆e1┆:↲
↲
╞ ok╞ ╞ (0) : message processed properly.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ┆a1┆Message name┆e1┆: dte_test_message↲
↲
╞ ┆a1┆Message format┆e1┆:↲
╞ ╞ message recv.↲
╞ u1╞ ╞ 3↲
╞ u2╞ ╞ 7↲
╞ u3╞ process_type↲
╞ u4╞ ╞ 0↲
↲
╞ buf╞ testbuf↲
↲
╞ testbuf = record↲
╞ ╞ first, last, next : integer;↲
╞ ╞ testarea : ┆84┆array (0.. testmax) of↲
╞ ╞ ╞ ╞ testrecords;↲
╞ ╞ end;↲
↲
╞ ┆84┆The different testrecords are explained in subsection 6.2.4.↲
↲
╞ ┆a1┆Function┆e1┆:↲
↲
╞ ┆84┆The dtetest process checks if the testrecords shall be printed ↓
┆19┆┆89┆┄┄immediately, and if so the proper actions are performed. If not, ↓
┆19┆┆89┆┄┄the value of u4 is changed to not_printed (=1) and the message is ↓
┆19┆┆89┆┄┄queued at the testbuffer hook (testsem) for later printing if re┄↓
┆19┆┆89┆┄┄quired.↲
↲
╞ process_type is:↲
↲
╞ 0 : dte process↲
╞ 1 : dte_lcnzero process↲
╞ 3+y : dte_chan process incarnation number y (dte_chany).↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆b0┆┆a1┆Message name:┆e1┆ dte_access_test↲
↲
╞ ┆a1┆Message format:↲
╞ ╞ message sent answer recv.↲
╞ u1╞ ╞ func╞ ╞ ╞ unch↲
╞ u2╞ ╞ 7╞ ╞ ill_opcode↲
╞ u3╞ user_no/stream_no/ch_index╞ unch↲
╞ u4╞ -╞ ╞ see below↲
↲
╞ buf╞ -╞ ╞ testbuf↲
↲
╞ testbuf = array (1..14) of bytes;↲
↲
╞ ┆a1┆Function:↲
↲
╞ ┆84┆A dte_access test message is received and the testbuf is printed ↓
┆19┆┆89┆┄┄on the console, each byte both as a digit and hexadecimal. The ↓
┆19┆┆89┆┄┄dtetest process generates the test message on operator request ↓
┆19┆┆89┆┄┄(see subsection 6.2.3) and sends it to the dte_access process. ↓
┆19┆┆89┆┄┄Func specifies which variable values the dte_access process shall ↓
┆19┆┆89┆┄┄return. The correlation between func and u3 is :↲
↲
╞ ╞ func╞ u3╞ ╞ variable↲
╞ ╞ 128╞ user_no╞ ╞ user_table↲
╞ ╞ 160╞ stream_no╞ ╞ stream_table↲
╞ ╞ 224╞ ch_index╞ ╞ channel_table↲
↲
╞ ┆84┆The user_no, stream_no and ch_index may be changed in the dte_ac┄↓
┆19┆┆89┆┄┄cess process, if it is outside the interval defined for the table ↓
┆19┆┆89┆┄┄in question. The returned value (in u4) is the nearest limit.↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆6.2.3╞ Operator Commands.↲
↲
╞ ┆84┆As mentioned in subsection 6.2.1 the operator can control the test ↓
┆19┆┆89┆┄┄generation and printing from the console and generate dte_access ↓
┆19┆┆89┆┄┄test messages. To support this control the following commands are ↓
┆19┆┆89┆┄┄available:↲
↲
╞ ┆84┆In the commands <process name> has to be substituted with one of ↓
┆19┆┆89┆┄┄the following↲
╞ ╞ dte_sup for the dte process↲
╞ ╞ dte_chan for the dte_chan processes↲
╞ ╞ dte_lcnzero for the dte_lcnzero process.↲
↲
↲
┆b0┆╞ start <process name> run↲
↲
╞ ┆84┆Testrecord generation is started in the specified process or if ↓
┆19┆┆89┆┄┄the option is ┆b0┆run ┆f0┆immediately print of testbuffers is started.↲
↲
↲
┆b0┆╞ stop <process name> run↲
↲
╞ ┆84┆Testrecord generation is stopped in the specified process or if ↓
┆19┆┆89┆┄┄the option is ┆b0┆run ┆f0┆the immediately print of testbuffers is stopped.↲
↲
↲
┆b0┆╞ print <process name> test_rec↲
↲
╞ ┆84┆The queued testbuffers from the specified process, which not al┄↓
┆19┆┆89┆┄┄ready are printed, are printed in a predefined format (see subsec┄↓
┆19┆┆89┆┄┄tion 6.2.4). Furthermore a bit is set indicating that the next ↓
┆19┆┆89┆┄┄buffer received from the process shall be printed. If the option ↓
┆19┆┆89┆┄┄┆b0┆test_rec ┆f0┆is used, the value of the testbits record is printed. If ↓
┆19┆┆89┆┆81┆┄a testbit is true a text is printed otherwise nothing. The corre┄↓
┆19┆┆89┆┆81┆┄la┄tion be┄tween texts and bits are:↲
════════════════════════════════════════════════════════════════════════
↓
╞ dte test generation╞ bit 1 : DTE_SUP↲
╞ dte_chan test generation bit 2 : DTE_CHAN↲
╞ dte_lcnzero test generation bit 3 : DTE_LCNZERO↲
╞ version print╞ bit 4 : CONSOLE ID↲
╞ line state printing╞ bit 5 : HDLC_STATE↲
╞ level 3 restart printing bit 6 : LEVEL3_MESS↲
╞ modem signals printing bit 7 : MODEM_SIGNAL↲
╞ line event printing bit 8 : HDLC_EVENT↲
↲
┆b0┆╞ provoke dte_sup dte_lcnzero dte_chan <no>↲
↲
╞ ┆84┆The DTE module is required to provoke the specified process incar┄↓
┆19┆┆89┆┄┄nation to copy the current testarea to a testbuffer and return ↓
┆19┆┆89┆┄┄this to the dtetest process. <no> specifies the last three digits ↓
┆19┆┆89┆┄┄in the dte_chan incarnation name, which can be obtained utilizing ↓
┆19┆┆89┆┄┄the OPSYS command '┆b0┆list┆f0┆'.↲
↲
╞ ┆b0┆create <func> <no>↲
↲
╞ ┆84┆A dte_access test message is generate and sent to the dte_access ↓
┆19┆┆89┆┄┄process. Only one test message can be outstanding. When the ↓
┆19┆┆89┆┄┄message is returned from the dte_access process, the buffer is ↓
┆19┆┆89┆┄┄printed on the console (please see subsection 6.2.4.5). The ↓
┆19┆┆89┆┄┄following values of func are allowed :↲
↲
╞ <func>╞ u1╞ <no>╞ ╞ buffer at return↲
╞ 1╞ 128 = (1*4+0)*32╞ user number╞ ┆84┆contains infor┄↓
┆19┆┆bb┆┄┄mation from ↓
┆19┆┆bb┆┄┄user_table(user ↓
┆19┆┆bb┆┄┄number)↲
╞ 2╞ 160 = (1*4+1)*32╞ stream number ╞ ┆84┆contains infor┄↓
┆19┆┆bb┆┄┄mation from ↓
┆19┆┆bb┆┄┄stream_table(stream ↓
┆19┆┆bb┆┄┄number)↲
╞ 3╞ 224 = (1*4+3)*32╞ channel index╞ ┆84┆contains infor┄↓
┆19┆┆bb┆┄┄mation from ↓
┆19┆┆bb┆┄┄channel_table(channel ↓
┆19┆┆bb┆┄┄index)↲
↲
┆8c┆┄┆a7┆↓
╞ ┆84┆If <no> is smaller than 1 it is set to 1 and if it is greater than ↓
┆19┆┆89┆┄┄255 it is set to 255.↲
↲
↲
┆a1┆6.2.4╞ Testoutput Description.↲
↲
╞ ┆84┆In the following three subsections are the format of the testre┄↓
┆19┆┆89┆┄┄cords and testoutput print described. Each subsection is dedicated ↓
┆19┆┆89┆┄┄to one process. In subsection 6.2.4.4 the printed text concer┄ning ↓
┆19┆┆89┆┄┄the status of the communication line are shown and explained, and ↓
┆19┆┆89┆┄┄in the last subsection the dte_access test message buffer.↲
↲
╞ ┆84┆Several of the test informations are written as text strings on ↓
┆19┆┆89┆┄┄the console. These text strings are all marked with (*) and out┄↓
┆19┆┆89┆┄┄lined in appendix D.2. Furthermore are two examples of a testout ↓
┆19┆┆89┆┄┄print shown in appendix D.3.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆6.2.4.1╞ Testoutput from Process dte.↲
↲
╞ ┆84┆The testrecords generated in the dte process have the following ↓
┆19┆┆89┆┄┄format:↲
↲
╞ packed record↲
╞ ╞ time╞ : integer;↲
╞ ╞ kind╞ : 0..15;↲
╞ ╞ state╞ : 0..3;↲
╞ ╞ fbool╞ : 0..1;↲
╞ ╞ dummy╞ : 0..1;↲
╞ ╞ fb1,↲
╞ ╞ fb2╞ : byte;↲
╞ ╞ fi╞ : integer;↲
╞ ╞ end;↲
↲
↲
╞ time╞ ╞ : Global dte time stamp.↲
╞ kind (*)╞ : Testrecord type (see table 9).↲
╞ state (*)╞ : ┆84┆The current value of the dte state variable ↓
┆19┆┆9f┆┄┄in the dte process.↲
╞ fbool╞ ╞ : Boolean parameter field.↲
╞ fb1, fb2╞ : Byte parameter fields.↲
╞ fi╞ ╞ : Integer parameter field.↲
↲
╞ ┆84┆fbool, fb1, fb2, and fi contains different information depending ↓
┆19┆┆89┆┄┄of kind. In table 9 the connections between kind and the parameter ↓
┆19┆┆89┆┄┄fields are shown.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Table 9: Process dte, testrecord kind and parameter fields.↲
════════════════════════════════════════════════════════════════════════
↓
┆84┆In the dtetest process each testrecord is processed and formatted ↓
┆19┆┆89┆┄┄to one print line with the format:↲
↲
┆b0┆╞ <time> <kind> <dte state> <fbool> <fb1> <fb2> <fi>↲
↲
╞ ┆84┆except if kind = 15, in which case <dte state> and <fbool> are ↓
┆19┆┆89┆┄┄out┄mitted.↲
↲
╞ ┆84┆The text printed for the different kind values are shown in table ↓
┆19┆┆89┆┄┄9, whereas the texts printed for the other fields are outlined in ↓
┆19┆┆89┆┄┄ap┄pendix D.2.↲
↲
↲
┆a1┆6.2.4.2╞ Testoutput from Process dte_lcnzero.↲
↲
╞ ┆84┆The testrecords generated in the dte_lcnzero process have the fol┄↓
┆19┆┆89┆┄┄lowing format:↲
↲
╞ packed record↲
╞ ╞ time╞ : integer;↲
╞ ╞ kind╞ : 0..15;↲
╞ ╞ state╞ : 0..3;↲
╞ ╞ dummy╞ : 0..3;↲
╞ ╞ field1,↲
╞ ╞ field2,↲
╞ ╞ field3╞ : byte;↲
╞ ╞ end;↲
↲
╞ time╞ ╞ : Global dte time stamp.↲
╞ kind (*)╞ ╞ : Testrecord type (see table 10).↲
╞ state (*)╞ ╞ : ┆84┆The current value of the dte state vari┄↓
┆19┆┆a1┆┄┄able in the dte_lcnzero process.↲
╞ field1, field2, field3: ┆84┆Parameter fields depending of kind. The ↓
┆19┆┆a1┆┄┄connections are shown in table 10.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Table 10: ┆84┆Process dte_lcnzero, testrecord kind and parameter ↓
┆19┆┆93┆┄┄fields.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆In the dtetest process each testrecord is processed and formatted ↓
┆19┆┆89┆┄┄to one print line with the format:↲
↲
┆b0┆╞ <time> <kind> <dte state> <field1> <field2> <field3> <aux>↲
↲
╞ ┆84┆<aux> depends of the type of testrecord (kind). In appendix D.2 ↓
┆19┆┆89┆┄┄these dependants are outlined.↲
↲
╞ ┆84┆The text printed for the different kind values are shown in table ↓
┆19┆┆89┆┄┄10, whereas the texts printed for the other fields are outlined in ↓
┆19┆┆89┆┄┄appendix D.2.↲
↲
↲
┆a1┆6.2.4.3╞ Testoutput from Process dte_chan.↲
↲
╞ ┆84┆The testrecords generated in the dte_chan process have the follow┄↓
┆19┆┆89┆┄┄ing format:↲
↲
╞ packed record↲
╞ ╞ time╞ : integer;↲
╞ ╞ kind╞ : 0..15;↲
╞ ╞ c_active,↲
╞ ╞ field5╞ : boolean;↲
╞ ╞ dummy1╞ : 0..3;↲
╞ ╞ state╞ : 0..31;↲
╞ ╞ dummy2╞ : 0..7;↲
╞ ╞ field1,↲
╞ ╞ field2,↲
╞ ╞ field3,↲
╞ ╞ field4╞ : byte;↲
╞ ╞ end;↲
↲
╞ time╞ ╞ : Global dte time stamp.↲
╞ kind (*)╞ ╞ : Testrecord type (see table 11).↲
╞ c_active (*)╞ : ┆84┆The variable 'chan_active', which is true if ↓
┆19┆┆9f┆┄┄the dte_chan process incarnation is active.↲
╞ state (*)╞ ╞ : ┆84┆The current value of the variable↲
┆84┆'chan_rec.chan_state'.↲
╞ field1, field2, field3,↲
╞ field4, field5 (*)╞ : ┆84┆Parameter fields depending of kind. The con┄↓
┆19┆┆9f┆┄┄nections are shown in table 11.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Table 11: Process dte_chan, testrecord kind and parameter fields.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆In the dtetest process each testrecord is processed and formatted ↓
┆19┆┆89┆┄┄to one print line with the format:↲
↲
↲
╞ ┆b0┆<time> <kind> <state> <c_active> <field5>↲
╞ ┆b0┆┆84┆<dec.field1> <hex.field1> <dec.field2> <hex.field2> <dec.field3> ↓
┆19┆┆89┆┆81┆┆82┆<hex.field3> <dec.field4> <hex.field 4> <aux>↲
↲
↲
╞ ┆84┆<aux> depends of the type of testrecord (kind) and in appendix D.2 ↓
┆19┆┆89┆┄┄these dependants are outlined.↲
↲
┆84┆The text printed for the different kind values are shown in table ↓
┆19┆┆89┆┄┄11, whereas the texts printed for the other fields are outlined in ↓
┆19┆┆89┆┄┄appendix D.2.↲
↲
↲
┆a1┆6.2.4.4╞ Communication Line Status Information.↲
↲
╞ ┆84┆As mentioned in subsection 6.2.1 different information concerning ↓
┆19┆┆89┆┄┄the status of the communication line may be printed on the con┄↓
┆19┆┆89┆┄┄sole. Below are each text printed described and they are groupped ↓
┆19┆┆89┆┄┄according to which bit setting in the testbits record, that will ↓
┆19┆┆89┆┄┄provoke the print. The internal dte procedure ┆b0┆dte_message┆f0┆ is used ↓
┆19┆┆89┆┆81┆┄to format the printed text. <hh.mm.ss> is time (hour, minute, ↓
┆19┆┆89┆┆81┆┄second) when the DTE observes the event.↲
↲
┆b0┆╞ ┆a1┆line event↲
↲
╞ ┆a1┆┆e1┆ <hh.mm.ss> line up↲
↲
╞ ┆84┆The communicaiton line is connected on level 2 (hdlc connection ↓
┆19┆┆89┆┄┄performed).↲
↲
↲
╞ ┆a1┆┆e1┆ <hh.mm.ss> line event <xx>↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆An hdlc line event has been reported to the DTE.↲
╞ ┆84┆The line state is not changed. <xx> is the event number returned ↓
┆19┆┆89┆┄┄from the HDLC (please refer to ref. (9)).↲
↲
╞ ┆a1┆┆e1┆ <hh.mm.ss> line down↲
↲
╞ The communicaiton line is disconnected.↲
╞ The previous state was level 2 ready.↲
↲
┆e1┆╞ ┆a1┆┆e1┆ <hh.mm.ss> network down↲
↲
↲
╞ The communicaiton line is disconnected.↲
╞ The previous state was level 3 ready.↲
↲
↲
┆b0┆╞ ┆a1┆modem signals↲
↲
↲
╞ modem signals : DTR=<x> RTS=<x> RI=<x> SQD=<x>┆e1┆ DSR=<x> DCD=<x>↲
↲
↲
╞ ┆84┆The value of the modem signals are printed. <x> will be either 0 ↓
┆19┆┆89┆┄┄or 1, signal not set or signal set respectively.↲
↲
↲
┆b0┆╞ ┆a1┆level 3 restart↲
↲
↲
╞ ┆a1┆┆e1┆ <hh.mm.ss> dte restarted↲
↲
↲
╞ ┆84┆The DTE has received a RESTART INDICATION packet from the DCE, ↓
┆19┆┆89┆┄┄and has conformed it. The restart phase is initiated.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆a1┆┆e1┆ <hh.mm.ss> dte restart timeout <no>↲
↲
╞ ┆84┆A restart timeout has occured in the DTE. A new RESTART REQUEST ↓
┆19┆┆89┆┄┄packet is transmitted to the DCE. <no> is the restart timeout ↓
┆19┆┆89┆┄┄periode in seconds.↲
↲
╞ ┆a1┆┆e1┆ <hh.mm.ss> dte restarted by NC↲
↲
╞ ┆84┆The DTE has initiated a restart phase requested by the NC (by ↓
┆19┆┆89┆┄┄the LCP operation DTE 54,0).↲
↲
↲
╞ ┆a1┆┆b0┆line state↲
↲
↲
╞ ┆a1┆┆e1┆ internal line state : <text> : <xx>↲
↲
↲
╞ ┆84┆An event buffer has been returned from the HDLC, indicating a line ↓
┆19┆┆89┆┄┄event. <text> is the dte internal line state and is printed as ↓
┆19┆┆89┆┄┄(connected, connecting, d_connecting, disc_recv, disconnected) and ↓
┆19┆┆89┆┄┄equals the states described in subsection 4.2.2. <no> is the line ↓
┆19┆┆89┆┄┄event number returned from the HDLC (please refer to ref. (9)).↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆6.2.4.5╞ dte_access Test Message Print.↲
↲
╞ ┆84┆The contens of testbuf (subsection 6.2.2 message ┆b0┆dte_access_test┆f0┆) ↓
┆19┆┆89┆┆81┆┄depends on the u1 value. Testbuf is an array of 14 bytes, which ↓
┆19┆┆89┆┆81┆┄contain the following information :↲
↲
╞ func 1 (128) 2 (160) 3 (224)↲
╞ testbuf byte↲
╞ 1╞ user state╞ stream state╞ conn stream/255↲
╞ 2╞ no of user streams╞ user index╞ not used↲
╞ 3╞ no of lost stream╞ channel number╞ not used↲
╞ ╞ events↲
╞ 4╞ no of lost user╞ no. of buffers at╞ not used↲
╞ ╞ events╞ ╞ suspend sem↲
╞ 5╞ no of buffers at╞ 0╞ ╞ not used↲
╞ ╞ event sem↲
╞ 6╞ no of buffers at╞ 0= internal ref nil╞ not used↲
╞ ╞ general sem╞ 1= int. ref not nil↲
╞ 7╞ lost user event,╞ 0╞ ╞ not used↲
╞ ╞ type↲
╞ 8╞ lost user event,╞ intern state╞ not used↲
╞ ╞ cause↲
╞ 9╞ lost user event,╞ 0╞ ╞ not used↲
╞ ╞ diagnostic↲
╞ 10╞ not used╞ ╞ 0╞ ╞ not used↲
╞ 11╞ not used╞ ╞ lost stream event,╞ not used↲
╞ ╞ ╞ ╞ type↲
╞ 12╞ not used╞ ╞ lost stream event,╞ not used↲
╞ ╞ ╞ ╞ cause↲
╞ 13╞ not used╞ ╞ lost stream event,╞ not used↲
╞ ╞ ╞ ╞ diagnostic↲
╞ 14╞ not used╞ ╞ no of lost events╞ not used↲
↲
╞ ┆84┆The printing on the console will contain a header line↲
↲
╞ ╞ ╞ ┆b0┆user index :↲
╞ ┆b0┆Operation : <func> stream no : <u3> / <u4>↲
╞ ╞ ╞ ┆b0┆stream no :↲
↲
┆8c┆┄┆a7┆↓
╞ ┆84┆This line will be followed by a line where each byte in the ↓
┆19┆┆89┆┄┄testbuf is printed as a digit and one line where the byte is ↓
┆19┆┆89┆┄┄printed hexadecimal.↲
↲
╞ ┆84┆For the state variables and event types the following interpre┄↓
┆19┆┆89┆┄┄tation can be applied :↲
↲
╞ ┆a1┆user state┆e1┆ (please see also subsection 4.3.2)↲
╞ ╞ 0 = free↲
╞ ╞ 1 = w_resc↲
╞ ╞ 2 = idle↲
╞ ╞ 3 = active↲
↲
╞ ┆a1┆stream state┆e1┆ (please see also subsection 4.3.2)↲
╞ ╞ 0 = clear↲
╞ ╞ 1 = w_uresp↲
╞ ╞ 2 = w_accp↲
╞ ╞ 3 = data↲
╞ ╞ 4 = u_clear↲
↲
╞ ┆a1┆intern state┆e1┆ (please see also subsection 4.3.2)↲
╞ ╞ 0 = cleared↲
╞ ╞ 2 = waiting↲
╞ ╞ 3 = data_xfer↲
╞ ╞ 4 = clearing↲
↲
╞ ┆a1┆event type┆e1┆↲
╞ ╞ 16 = dte_ev_disc,╞ line disconnected↲
╞ ╞ 24 = dte_ev_clear,╞ stream cleared↲
╞ ╞ 32 = dte_ev_rstst,╞ dte restarted↲
╞ ╞ 40 = dte_ev_reset,╞ stream reset↲
╞ ╞ 48 = dte_ev_inc,╞ INCOMING CALL lost↲
╞ ╞ 56 = dte_ev_data,╞ DATA packet lost↲
╞ ╞ 64 = dte_ev_intrupt, INTERRUPT packet lost↲
↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆6.3╞ Message Snoop.↲
↲
╞ ┆84┆In order to snoop messages and answers received at not global ↓
┆19┆┆89┆┄┄known semaphores, the dte process can start an incarnation of the ↓
┆19┆┆89┆┄┄gene┄ral snooper process. This incarnation is called dtesnoop. The ↓
┆19┆┆89┆┄┄ge┄neral snooper is described in ref. (7).↲
↲
╞ ┆84┆The semaphores that can be snooped are the main input and sync se┄↓
┆19┆┆89┆┄┄maphores of the dte_chan process incarnations (in the dte process ↓
┆19┆┆89┆┄┄the chan_vector and sync_vector).↲
↲
╞ ┆84┆One configuration parameter to the dtesnoop process is 'max_pick┄↓
┆19┆┆89┆┄┄ups'. If max_pickups is greater than twice the maximum number of ↓
┆19┆┆89┆┄┄channel processes (max_chan) both the input and sync semaphores ↓
┆19┆┆89┆┄┄are snooped. If it is greater than max_chan but smaller than twice ↓
┆19┆┆89┆┄┄max_chan only the input semaphores are snooped, and if it is smal┄↓
┆19┆┆89┆┄┄ler than max_chan no semaphores are snooped. The followning rules ↓
┆19┆┆89┆┄┄can be applied:↲
↲
╞ max_pickups ┆a1┆>┆e1┆ 2 * max_chan : input and sync semaphores↲
╞ 2 * max_chan > max_pickups ┆a1┆>┆e1┆ max_chan : input semaphores only↲
╞ max_chan > max_pickups ╞ : none.↲
════════════════════════════════════════════════════════════════════════
↓
«index» formatlinie til RC manualer↲
┆14┆┆b3┆↲
┆14┆┆b3┆┆06┆- ┆0b┆ -↲
↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆7.╞ CONFIGURATION GUIDE.↲
↲
╞ ┆84┆This chapter will give a short description of the configuration ↓
┆19┆┆89┆┄┄constants, the storage requirements and the compilation of the DTE ↓
┆19┆┆89┆┄┄System.↲
↲
↲
┆a1┆7.1╞ Configuration Parameters.↲
↲
╞ ┆84┆In the DTE System principel many parameters can be changed in ↓
┆19┆┆89┆┄┄order to optimize the storage requirements and performance of the ↓
┆19┆┆89┆┄┄modules:↲
╞ ┆84┆Several of these parameters are allready optimized, so in the next ↓
┆19┆┆89┆┄┄two subsections only the parameters of normally interest are des┄↓
┆19┆┆89┆┄┄cribed. They can be divided into two groups, one where the parame┄↓
┆19┆┆89┆┄┄ter values must be defined at compilation time (subsection 7.1.1) ↓
┆19┆┆89┆┄┄and one where the parameter values are defined at incarnation cre┄↓
┆19┆┆89┆┄┄ate time (subsection 7.1.2).↲
↲
╞ ┆84┆In subsection 7.1.3 are the default values of some interesting DTE ↓
┆19┆┆89┆┄┄parameters outlined, and in subsection 7.1.4 are parameters con┄↓
┆19┆┆89┆┄┄cer┄ning the trace, test and snoop systems described.↲
↲
↲
┆a1┆7.1.1╞ Compilation Parameters.↲
↲
╞ ┆84┆These parameters are found in the configuration environment (stan┄↓
┆19┆┆89┆┄┄dard : STDCONF) and in DTEENV.↲
↲
┆b0┆╞ m_max_chan╞ ┆f0┆: ┆84┆Defines the maximum of logical channels ↓
┆19┆┆9f┆┆81┆┄(dte_chan process incarnations) the DTE can ↓
┆19┆┆9f┆┆81┆┄handle simultaneously (┆b0┆in STDCONF set to ↓
┆19┆┆9f┆┆82┆┆82┆20┆f0┆).↲
↲
┆b0┆╞ max_user╞ ╞ ┆f0┆: ┆84┆Defines the maximum of simultaneously con┄↓
┆19┆┆9f┆┆81┆┄nected users (┆b0┆in STDCONF set to 5┆f0┆).↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ max_inbufs╞ ┆f0┆: ┆84┆Defines the maximum of input buffers the ↓
┆19┆┆9f┆┆81┆┄dte_hrec process tries to maintain at the ↓
┆19┆┆9f┆┆81┆┄HDLC. The ac┄tual value may be changed by an ↓
┆19┆┆9f┆┆81┆┄LCP opera┄tion (DTE 54,0) and the default va┄↓
┆19┆┆9f┆┆81┆┄lue is outlined in subsection 7.1.3. (┆b0┆in ↓
┆19┆┆9f┆┆82┆┆82┆DTE┄ENV set to 10┆f0┆).↲
↲
┆b0┆╞ testmax╞ ╞ ┆f0┆: ┆84┆Defines the number of test records in the ↓
┆19┆┆9f┆┆81┆┄internal testareas and in the testbuffers ↓
┆19┆┆9f┆┆81┆┄(┆b0┆in DTEENV set to 20┆f0┆).↲
↲
↲
┆a1┆7.1.2╞ Creation Parameters.↲
↲
╞ ┆84┆At creation time it is possible to define several parameters of ↓
┆19┆┆89┆┄┄the DTE System. They are gathered in four record types.↲
↲
╞ hdlc_cp_type╞ : ┆84┆Parameters for the HDLC communication.↲
↲
╞ dte_cp_type╞ : ┆84┆Parameters concerning the DTE and X.25 com┄↓
┆19┆┆9f┆┄┄munication.↲
↲
╞ dte_pc_type╞ : ┆84┆Parameters for buffer pools configuration.↲
↲
╞ dte_dc_type╞ : ┆84┆Parameters concerning the debug, trace and ↓
┆19┆┆9f┆┄┄test facilities.↲
↲
╞ ┆84┆These four types are defined in CNNETENV and a default value is ↓
┆19┆┆89┆┄┄assigned to them in CRPARMENV.↲
↲
╞ ┆84┆The individuel fields are described in subsection 4.2.1 so here ↓
┆19┆┆89┆┄┄will only a recommended value be mentioned. A question mark indi┄↓
┆19┆┆89┆┄┄cates that the value depends on the system the DTE is running in.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ hdlc_cp_type:↲
╞ test_modem╞ : ?↲
╞ com204╞ ╞ : normally true↲
╞ c_id╞ ╞ : 2100╞ (= 2.1 secs.)↲
╞ t1╞ ╞ : 1400 (= 1.4 secs.)↲
╞ n2╞ ╞ : 10↲
╞ k╞ ╞ : 6↲
╞ framespace╞ : 4 (= 40 microsecs.)↲
╞ abortspace╞ : 2╞ (= 20 microsecs.)↲
↲
╞ dte_cp_type:↲
╞ x25_lcg╞ : ?↲
╞ dltc╞ ╞ : ?↲
╞ dhtc╞ ╞ : ? (<= dltc + max_chan)↲
╞ max_chan╞ : ?↲
╞ dw_size╞ : normally 2↲
mw_size : ?↲
user_length╞ : actual_u_lgt (defined in CNNETENV)↲
╞ x25_datasize : ?↲
↲
╞ dte_pc_type:↲
╞ suphead_no╞ : 6↲
╞ supmess_no╞ : 6↲
╞ eventbuf_no╞ : 3↲
╞ hdlc_eventno╞ : 3↲
↲
╞ dte_dc_type:↲
╞ dtetest╞ : false↲
╞ snoop_on╞ : false↲
╞ def_trace╞ : false↲
╞ def_test╞ : ?, ?, ?, true, false, true, ?, ?↲
↲
╞ ┆84┆Some of the parameters can be changed by an LCP operation:↲
↲
╞ dltc, dhtc╞ : DTE 54,0↲
╞ def_trace╞ : DTE 53,0↲
╞ def_test╞ : DTE 52,0↲
↲
╞ ┆84┆Furthermore def_test can be changed partly from the console (sec┄↓
┆19┆┆89┆┄┄tion 6.2).↲
↲
↲
┆8c┆┄┆aa┆↓
┆a1┆7.1.3╞ Special Default Values.↲
↲
╞ ┆84┆As mentioned in subsection 4.1.4 several timers are used in the ↓
┆19┆┆89┆┄┄DTE module. The value (may be only a default value) of these ti┄↓
┆19┆┆89┆┄┄mers are defined in DTEENV in the record timer_def.↲
╞ The following values are recommended:↲
↲
╞ t11m = 20 secs : < DCE call request timeout↲
╞ t12m = 20 secs : < DCE reset request timeout↲
╞ t21 = 200 secs : DTE call request timeout↲
╞ t22 = 180 secs : DTE reset request timeout↲
╞ t23 = 180 secs : DTE clear request timeout↲
╞ t30 = 30 secs : DTE idle timeout↲
╞ t31 = 30 secs : DTE data hold timeout↲
╞ ack_timer = 1 sec : DTE acknowledge delay timeout↲
╞ t20 = 180 secs : DTE restart request timeout↲
╞ t50 = 1 sec : Timer period for sense DSR set↲
╞ t51 = 2 secs : Timer period for sense DCD set↲
╞ t52 = 5 secs : ┆84┆Timer period to get the modem signals in ↓
┆19┆┆a3┆┄┄a steady state↲
╞ t60 = 10 secs : ┆84┆Timer period before initiating NC re┄↓
┆19┆┆a3┆┄┄start.↲
↲
╞ ┆84┆t30 and ack_timer may be changed by the LCP operation DTE 54,0.↲
↲
╞ ┆84┆In connection with the NC system the DTE maintains a bit mask ↓
┆19┆┆89┆┄┄(nc_mask) defining which NC event, that shall be generated. In ↓
┆19┆┆89┆┄┄DTEENV a default value (dnc_mask) is defined. The value of this ↓
┆19┆┆89┆┄┄depends of the system the DTE is running in, and the information ↓
┆19┆┆89┆┄┄that is required for Network Control Management. The variable may ↓
┆19┆┆89┆┄┄be changed by the LCP operation DTE 1,0.↲
↲
╞ ┆84┆The dte_hrec process tries to maintain a certant number of input ↓
┆19┆┆89┆┄┄buffers at the HDLC. The default value (dn_buf) of this parameter ↓
┆19┆┆89┆┄┄is def┄ined in DTEENV (set to 5) and may be changed by the LCP op┄e┄↓
┆19┆┆89┆┄┄ration DTE 54,0. The upper limit for this parameter is max_inbufs ↓
┆19┆┆89┆┄┄(see subsection 7.1.1).↲
↲
↲
┆8c┆┄┆a7┆↓
┆a1┆7.1.4╞ Configuration of Trace, Test and Snoop Systems.↲
↲
╞ ┆84┆┆a1┆┆b0┆dtetrace↲
↲
╞ In this system two parameters are of interest:↲
↲
╞ trace_buf_no╞ : Number of trace buffers↲
╞ ╞ ╞ ┆b0┆(in dte_trace set to 10)↲
↲
╞ trace_buf_size╞ : Size in bytes of a trace buffer↲
┆b0┆╞ ╞ ╞ (in TRACEENV set to 300)↲
↲
↲
┆b0┆╞ ┆a1┆dtetest↲
↲
╞ The only parameter of interest is:↲
↲
╞ dtetestbufno╞ : Number of test buffers↲
┆b0┆╞ ╞ ╞ (in dte_test set to 20)↲
↲
↲
┆b0┆╞ ┆a1┆dtesnoop↲
↲
╞ The only parameter of interest is:↲
↲
╞ max_pickups╞ : ┆84┆Number of pickup processes. It is a compila┄↓
┆19┆┆9f┆┄┄tion parameter to the snooper process. It ↓
┆19┆┆9f┆┄┄should be greater than or equal to twice ↓
┆19┆┆9f┆┄┄max_chan (see section 6.3) if snoop shall be ↓
┆19┆┆9f┆┄┄performed.↲
┆b0┆╞ ╞ ╞ (in NETENV set to 20).↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆7.2╞ Storage Requirements.↲
↲
╞ ┆84┆This section lists the storage requirements for the DTE System. ↓
┆19┆┆89┆┄┄The reader is warned that the numerical values are subject to ↓
┆19┆┆89┆┄┄changes as new versions of the module, compiler or allocator algo┄↓
┆19┆┆89┆┄┄rithm emerge. Furthermore the storage requirements depends on some ↓
┆19┆┆89┆┄┄configuration parameters. The calculation will show these connec┄↓
┆19┆┆89┆┄┄tions and most of the parameters will be fixed to the value defin┄↓
┆19┆┆89┆┄┄ed by the current versions.↲
↲
╞ The current versions are↲
↲
╞ RC3502/1 Operating System, Release 6.01 84.04.05↲
╞ Real-Time Pascal, Release 8.01, 84.04.05↲
╞ DTE module, Version 14, 85.10.21↲
╞ DTETRACE, Version 6, 85.07.30↲
╞ DTETEST,╞ ╞ Version 16, 85.10.14↲
╞ DTESNOOP,╞ ╞ ╞ , 83.12.05.↲
↲
╞ ┆84┆The storage requirements may be divided into two:↲
╞ - ┆84┆the static requirements which are independent of the creation ↓
┆19┆┆8e┆┄┄pa┄rameters and↲
- ┆84┆the dynamic requirements which depend on the creation parame┄↓
┆19┆┆8e┆┄┄ters.↲
↲
╞ ┆84┆Orthogonally, storage is required for three different purposes: ↓
┆19┆┆89┆┄┄code, stacks and buffer pools.↲
↲
╞ ┆84┆The storage for code is of static type, whereas the storage for ↓
┆19┆┆89┆┄┄stacks and pools may be divided into a static and a dynamic part.↲
↲
╞ ┆84┆The following three subsections give the code, stack and pool re┄↓
┆19┆┆89┆┄┄quirements of the components of the DTE System, whereas subsection ↓
┆19┆┆89┆┄┄7.2.4 gives an overview of the total requirements.↲
↲
╞ ┆84┆As mentioned above several of the configuration parameters will be ↓
┆19┆┆89┆┄┄fixed in the calculation. ┆b0┆Only in subsection 7.2.4 ┆f0┆the parameters ↓
┆19┆┆89┆┆81┆┄will be fixed. The only two parameters that not will be fixed are ↓
┆19┆┆89┆┆81┆┄the actual number of logical channels (max_chan), and the max ↓
┆19┆┆89┆┆81┆┄window size (mw_size).↲
↲
┆8c┆┄┆a9┆↓
╞ ┆84┆This means that the dynamic parts in subsection 7.2.4 will only ↓
┆19┆┆89┆┄┄depend of the value of↲
↲
╞ ╞ ╞ N = max_chan.↲
╞ ╞ ╞ W = mw_size↲
↲
↲
┆a1┆7.2.1╞ Code.↲
↲
╞ ┆84┆The specified requirements are those obtained by means of the ↓
┆19┆┆89┆┄┄PLIBLOOKUP utility.↲
↲
╞ process/procedure name╞ ╞ bytes↲
╞ ╞ dte╞ ╞ ╞ 31244↲
╞ ╞ dte_access╞ ╞ 7960↲
╞ ╞ dte_chan╞ ╞ ╞ 23946↲
╞ ╞ dte_lcnzero╞ ╞ 5276↲
╞ ╞ dte_hrec╞ ╞ ╞ 1644↲
╞ ╞ dte_pool╞ ╞ ╞ 1430↲
↲
╞ ╞ dtetrace╞ ╞ ╞ 4242↲
╞ ╞ outtrace╞ ╞ ╞ 348↲
↲
╞ ╞ dtetest╞ ╞ ╞ 9792↲
↲
╞ ╞ dte procedures╞ ╞ 5344↲
╞ ╞ X.25 procedures╞ ╞ 7042↲
╞ ╞ pool procedures╞ ╞ 1766↲
↲
╞ ╞ dtesnoop╞ ╞ ╞ 13000↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆7.2.2╞ Stack.↲
↲
╞ dte:╞ ╞ ╞ ╞ ╞ bytes↲
╞ basic╞ ╞ ╞ ╞ ╞ 2329↲
╞ extra per compilation defined channel (m_max_chan) ╞ 16↲
╞ extra per possible user (max_user)╞ 27↲
╞ extra per testrecord (testmax)╞ 7↲
╞ extra per creation defined channel (max_chan)╞ 71↲
↲
╞ dte_access:↲
╞ basic╞ ╞ ╞ ╞ ╞ 464↲
╞ extra per creation defined channel (max_chan)╞ 30↲
↲
╞ dte_chan:↲
╞ basic╞ ╞ ╞ ╞ ╞ 1190↲
╞ extra per testrecord╞ ╞ (testmax) ╞ 8↲
↲
╞ dte_lcnzero:↲
╞ basic╞ ╞ ╞ ╞ ╞ 990↲
╞ extra per testrecord╞ ╞ (testmax) ╞ 6↲
↲
╞ dte_hrec:↲
╞ basic╞ ╞ ╞ ╞ ╞ 424↲
↲
╞ dte_pool:↲
╞ basic╞ ╞ ╞ ╞ ╞ 400↲
↲
╞ dtetrace:↲
╞ basic╞ ╞ ╞ ╞ ╞ 666↲
↲
╞ outtrace:↲
╞ basic╞ ╞ ╞ ╞ ╞ 312↲
↲
╞ dtetest:↲
╞ basic╞ ╞ ╞ ╞ ╞ 780↲
↲
dteclock:↲
basic╞ ╞ ╞ ╞ ╞ 210↲
↲
┆8c┆┄┆a7┆↓
╞ dtesnoop:↲
╞ basic╞ ╞ ╞ ╞ ╞ 610↲
╞ extra per pickup incarnation (max_pickups) 340↲
↲
↲
┆a1┆7.2.3╞ Buffer Pools.↲
↲
╞ ┆84┆In this subsection the buffer requirements are outlined. Some of ↓
┆19┆┆89┆┄┄the pools are initialized dynamicly during normal run. They are ↓
┆19┆┆89┆┄┄mark with 'dyn' and a normal used number is estimated and used to ↓
┆19┆┆89┆┄┄calculate the requirements. This number is indicated in brackets ↓
┆19┆┆89┆┄┄after 'dyn'. The reader is warned that because of this the re┄↓
┆19┆┆89┆┄┄quirements may be greater in special situations.↲
↲
╞ process pool name number of buffer total↲
╞ ┆a1┆ buffers size bytes↲
↲
╞ ┆b0┆dte ┆f0┆trace_pool 1 32+0 32↲
╞ clock_pool 1 32+12 44↲
╞ console_pool 3 32+82 342↲
╞ break_pool 1 32+16 48↲
╞ head_pool suphead_no 32+0↲
╞ event_pool eventbuf_no 32+92↲
╞ supmesspool supmess_no 32+10↲
╞ lcp_pool 2 32+8 80↲
╞ sync_pool max_chan 32+16↲
╞ ch_res_pool max_chan 32+0↲
╞ hdlc_pool dyn (2) 32+20 104↲
╞ hdlc_ev_pool hdlc_eventno 32+0↲
╞ smallpool 2*max_chan 32+12↲
╞ bigpool max (max_inbufs,↲
╞ ╞ ╞ 6+max_chan* 32+9+x25_datasize↲
mw_size div 2)↲
╞ x25pool╞ max_chan 32+12↲
╞ bufkeypool 3 32+0 96↲
╞ shadow buffers 8 32+0 256↲
╞ chan shadow buf. max_chan 32+0↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ dte_access↲
┆f0┆control_pool dyn (3) 32+0↲
↲
┆b0┆╞ dte_chan ┆f0┆bookpool╞ ╞ 1╞ 32+6 38↲
╞ ╞ callpool╞ ╞ 2╞ 32+106 276↲
╞ ╞ headpool╞ ╞ 3╞ 32+0 96↲
╞ ╞ timeout_pool 3 32+2 102↲
╞ ╞ u_eventpool╞ 3╞ 32+10 126↲
╞ ╞ x25head_pool dyn (max 32+0 64↲
mw_size)↲
↲
┆b0┆╞ dte_lcnzero↲
┆f0┆console_pool 1 32+82 114↲
╞ ╞ headpool╞ ╞ 1╞ 32+0╞ ╞ 32↲
╞ ╞ supmess_pool dyn (2) 32+4 72↲
╞ ╞ timeout_pool 2╞ 32+12 88↲
↲
┆b0┆╞ dte_hrec ┆f0┆head_pool max_inbufs 32+0↲
╞ ╞ trace_pool 1 32+0 32↲
↲
┆b0┆╞ dte_pool ┆f0┆ncppool╞ ╞ 1╞ 32+8 40↲
╞ ╞ starthead╞ 1╞ 32+0 32↲
↲
┆b0┆╞ dtetrace ┆f0┆consolepool╞ 6╞ 32+82 684↲
╞ ╞ trace_pool trace_buf_no 32+8+trace_buf_size↲
╞ ╞ bufkeypool╞ 1╞ 32+0 32↲
╞ ╞ timepool╞ ╞ 1╞ 32+12 44↲
↲
┆b0┆╞ outtrace ┆f0┆trace_pool╞ 1╞ 32+0 32↲
↲
┆b0┆╞ dtetest ┆f0┆inpool╞ ╞ 1╞ 32+82╞ ╞ 114↲
╞ ╞ outpool╞ ╞ 3╞ 32+82╞ ╞ 342↲
╞ ╞ dtetestpool dtetestbufno 32+174↲
╞ ╞ acc_test ╞ ╞ 1╞ 32+14 46↲
↲
┆b0┆dtelock┆f0┆ timerpool 1 32+0 32↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆The figures for the dtesnoop process are taken from ref. (7) and ↓
┆19┆┆89┆┄┄gives:↲
↲
╞ message buffers╞ : 470 bytes + 130 bytes * max_pickups↲
╞ log buffer╞ : ┆84┆defined by command BZ but at least ╞ ╞ ╞ ↓
┆19┆┆9f┆┄┄┆84┆48 bytes + 2 bytes * (pick-up size) where ↓
┆19┆┆9f┆┄┄pick-up size is defined by the command PZ.↲
↲
╞ ┆84┆The above mentioned requirements can be summarized to↲
↲
┆b0┆╞ ┆a1┆dte↲
╞ 1002 + suphead_no * 32 + eventbuf_no * 124↲
╞ + supmess_no * 42 + hdlc_eventno * 32↲
╞ + max_chan * 244↲
╞ + max (max_inbufs, 6 + max_chan* mw_size div 2)↲
*(41 + x25_datasize) bytes.↲
↲
┆b0┆╞ ┆a1┆dte_access↲
╞ 96 bytes↲
↲
┆b0┆╞ ┆a1┆dte_chan↲
╞ 638 bytes + mw_size * 32↲
↲
┆b0┆╞ ┆a1┆dte_lcnzero↲
╞ 306 bytes↲
↲
┆b0┆╞ ┆84┆┆a1┆dte_hrec↲
╞ 32 + max_inbufs * 32 bytes↲
↲
┆b0┆╞ ┆a1┆dte_pool↲
╞ 72 bytes↲
↲
┆b0┆╞ ┆a1┆dtetrace↲
╞ 760 + trace_buf_no * (40 + trace_buf_size) bytes↲
↲
┆b0┆╞ ┆a1┆outtrace↲
╞ 32 bytes↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆ ┆a1┆dtetest↲
╞ 502 + dtetestbufno * 206 bytes↲
↲
┆b0┆┆a1┆dtelock↲
32↲
↲
┆b0┆╞ ┆a1┆dtesnoop↲
╞ 470 + max_pickups * 130 bytes + (log buffer)↲
↲
↲
┆a1┆7.2.4╞ Static and Dynamic Requirements.↲
↲
╞ ┆84┆The figures calculated in subsections 7.2.1 to 7.2.3 will with the ↓
┆19┆┆89┆┄┄parameter values defined for DTE Version 14 and the bellow de┄↓
┆19┆┆89┆┄┄scribed creation parameters give the requirements outlined in ↓
┆19┆┆89┆┄┄table 12.↲
↲
╞ Parameter values:↲
╞ m_max_chan╞ ╞ = 20↲
╞ max_user╞ ╞ = 5↲
╞ testmax╞ ╞ = 20↲
╞ max_pickups╞ ╞ = 20↲
╞ suphead_no╞ ╞ = 6↲
╞ eventbuf_no╞ ╞ = 3↲
╞ supmess_no╞ ╞ = 6↲
╞ hdlc_eventno╞ ╞ = 3↲
╞ max_inbufs╞ ╞ = 10↲
╞ x25_datasize╞ ╞ = 256↲
╞ trace_buf_no╞ ╞ = 10↲
╞ trace_buf_size╞ ╞ = 300↲
╞ dtetestbufno╞ ╞ = 20↲
╞ max_chan╞ ╞ = N↲
╞ mw_size = W↲
max_inbufs ┆a1┆<┆e1┆ 6 + N * W div 2↲
════════════════════════════════════════════════════════════════════════
↓
╞ process/procedures code stack buffers↲
┆81┆┆a1┆ bytes bytes bytes ╞ ╞ ↲
↲
dte 31244 2924 + 72*N 344 + 212*N + 149* ┆81┆┆a1┆N*W↲
┆81┆2↲
╞ dte_access 7960 464 + 30*N 96↲
dte_chan 23946 1350 638 + 32*W↲
╞ dte_lcnzero 5276 1110 306↲
╞ dte_hrec 1644 424 352↲
dte_pool 1430 400 72↲
↲
dte procedures 5344 - -↲
X25 procedures 7042 - -↲
pool procedures 1766 - -↲
↲
╞ dtetrace 4242 666 4160↲
╞ outtrace 348 312 32↲
↲
╞ dtetest 9792 780 4622↲
╞ dteclock - 210 32↲
↲
╞ dtesnoop 13000 7410 3070 + log buffer↲
↲
↲
↲
╞ Table 12: Storage requirements of the DTE System.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆Using this table the following static and dynamic requirements can ↓
┆19┆┆89┆┄┄be set up. W is set to 2 (normally default value).↲
↲
┆b0┆╞ ┆a1┆DTE module↲
↲
╞ Static:↲
╞ Code╞ ╞ ╞ 85652 bytes↲
╞ Stacks dte╞ ╞ ╞ 2924 -↲
╞ ╞ dte_access╞ ╞ 464 -↲
╞ ╞ dte_lcnzero╞ ╞ 1110 -↲
╞ ╞ dte_hrec╞ ╞ 424 -↲
╞ ╞ dte_pool╞ ╞ 400 -↲
╞ Pools dte╞ ╞ ╞ 344 -↲
╞ ╞ dte_access╞ ╞ 96 -↲
╞ ╞ dte_lcnzero╞ ╞ 306 -↲
╞ ╞ dte_hrec╞ ╞ 352 -↲
╞ ╞ dte_pool╞ ┆e1┆┆e1┆ ┆a1┆ 72 - ↲
╞ ╞ ╞ ╞ 92144 bytes↲
↲
╞ Dynamic at creation (per logical channel):↲
╞ Stacks dte╞ ╞ ╞ 72 bytes↲
╞ ╞ dte_access╞ ╞ 30 -↲
╞ Pools dte╞ ╞ ┆a1┆┆e1┆ ┆a1┆ 212 - ↲
╞ ╞ ╞ ╞ ╞ 314 bytes↲
↲
╞ Dynamic at runtime (per active logical channel):↲
╞ Stacks dte_chan╞ ╞ ╞ 1350 bytes↲
╞ Pools dte_chan╞ ╞ ╞ 638+32*2 ↲
╞ dte ┆a1┆ 149+212 ↲
╞ ╞ ╞ ╞ ╞ ╞ 2201 bytes↲
↲
╞ ┆84┆For the test, trace and snoop system static requirements means, ↓
┆19┆┆89┆┄┄what is required even if the system is not activated, but loaded, ↓
┆19┆┆89┆┄┄and dynamic is the requirements, when the system is active.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ┆a1┆Trace System↲
↲
╞ Static:↲
╞ Code╞ ╞ ╞ 4590 bytes↲
↲
╞ Dynamic:↲
╞ Stacks dtetrace╞ ╞ 666 bytes↲
╞ ╞ outtrace╞ ╞ 312 -↲
╞ Pools dtetrace ╞ ╞ 4160 -↲
╞ ╞ outtrace╞ ╞ ┆a1┆ 32 - ↲
╞ ╞ ╞ ╞ ╞ 5170 bytes↲
↲
┆b0┆╞ ┆a1┆Test System↲
↲
╞ Static:↲
╞ Code╞ ╞ ╞ 9792 bytes↲
╞ Stack╞ ╞ ╞ 990 -↲
╞ Pools╞ ╞ ┆a1┆╞ 4654 - ↲
╞ ╞ ╞ ╞ ╞ 13436 bytes↲
↲
┆b0┆╞ NB: The test system will allways be created, if it is loaded.↲
↲
↲
┆b0┆╞ ┆a1┆Snoop System↲
↲
╞ Static:↲
╞ Code╞ ╞ ┆a1┆┆e1┆╞ 13000 bytes↲
↲
╞ Dynamic:↲
╞ Stack dtesnoop╞ ╞ 7410 bytes↲
╞ Pools dtesnoop╞ ┆a1┆╞ 3070 - + log buffer ↲
╞ ╞ ╞ ╞ ╞ 10480 bytes + log buffer↲
↲
╞ ┆84┆From the above outlined figures the following systems requirements ↓
┆19┆┆89┆┄┄can be deduced.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ A) ┆a1┆DTE System without Test, Trace and Snoop Systems:↲
↲
╞ 92144 bytes + N * 314 bytes + N * 2201 bytes↲
↲
╞ B) ┆a1┆DTE System including Test System:↲
↲
╞ 107580 bytes + N * 314 bytes + N * 2201 bytes↲
↲
╞ C) ┆a1┆DTE System including Test and Trace System↲
↲
╞ trace not activated↲
╞ 112170 bytes + N * 314 bytes + N * 2201 bytes↲
↲
╞ trace activated↲
╞ 117340 bytes + N * 314 bytes + N * 2201 bytes↲
↲
╞ D) ┆a1┆DTE System including Snoop System (activated)↲
↲
╞ 116624 bytes + N * 314 bytes + N * 2201 bytes + log buffer.↲
↲
↲
┆a1┆7.3╞ Module Compilation.↲
↲
╞ ┆84┆In this section the jobs for compilation of the DTE System and ↓
┆19┆┆89┆┄┄listning of the source texts are explained.↲
↲
↲
┆a1┆7.3.1╞ Version Information.↲
↲
╞ ┆84┆When the DTE starts up different information are written on the ↓
┆19┆┆89┆┄┄console (see section 7.4 and 6.2). The version number and date of ↓
┆19┆┆89┆┄┄the DTE module are contained in the RC8000 file DTEINFOENV. ↓
┆19┆┆89┆┄┄Besides this version number each process of the DTE has its own ↓
┆19┆┆89┆┄┄version number, which is the first variable in the VAR section of ↓
┆19┆┆89┆┄┄the program. This may help the programmer in decoding an RC3502 ↓
┆19┆┆89┆┄┄stack dump.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆7.3.2╞ Compilation jobs.↲
↲
╞ ┆84┆To support the generation of a binary DTE module several jobs ↓
┆19┆┆89┆┄┄exists. They are gathered in the library (lib) file LIBJDTE.↲
↲
╞ The contents of LIBJDTE is↲
↲
╞ jdtegen╞ : DTE generation job↲
╞ jdtelib╞ : External DTE library generation job↲
╞ jdtelist╞ : DTE listning job↲
╞ jdteproc╞ : External DTE procedure generation job↲
╞ jdtetest╞ : Test System generation job↲
╞ jdtetrace╞ : Trace System generation job↲
╞ jdteutlist╞ : Job for listning of Test and Trace System↲
╞ jeditchenv╞ : Help job for the DTE generation↲
╞ jlibinsert╞ : Help job for the DTE generation↲
╞ jpoollib╞ : External pool library generation job↲
╞ jx25bib╞ : External X.25 library generation job↲
╞ jx25proc╞ : External X.25 procedure generation job↲
╞ stdconf╞ : Standard configuration file↲
╞ jdtepunch╞ : ┆84┆Job generating the DTE boot file from the ↓
┆19┆┆9f┆┄┄binary files.↲
↲
╞ ┆84┆All jobs will ask the operator some questions about name of source ↓
┆19┆┆89┆┄┄library, which process to compile/list and so on, and the operator ↓
┆19┆┆89┆┄┄can in this way choose to generate his own system. In ap┄pendix F ↓
┆19┆┆89┆┄┄some examples of this dialog is shown.↲
↲
╞ ┆84┆All tempory files are removed by the job after compilation/list┄↓
┆19┆┆89┆┄┄ning, and all binary files generated in the compilation will be ↓
┆19┆┆89┆┄┄created at ┆b0┆user scope.↲
↲
╞ ┆84┆After a compilation it is necessary to reformat the binary files ↓
┆19┆┆89┆┄┄with the job 'jdtepunch' also located in the job library LIBJDTE. ↓
┆19┆┆89┆┄┄The result of this is a boot file, DTEBOOT. During this reformat┄↓
┆19┆┆89┆┄┄ting it is possible to select whether the Test System and/or Trace ↓
┆19┆┆89┆┄┄System shall be included or not.↲
↲
╞ ┆84┆The Snoop System has to be part of the basic system or loaded se┄↓
┆19┆┆89┆┄┄peratly.↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆7.4╞ Creation of the DTE Module/System.↲
↲
╞ ┆84┆The module process parameters can, because the dte process is the ↓
┆19┆┆89┆┄┄parent process, be found in section 4.2 and 7.1.2.↲
↲
╞ ┆84┆The parent of the DTE System must supply the relevant parameters ↓
┆19┆┆89┆┄┄(see subsection 4.2.1), but only the following two are configura┄↓
┆19┆┆89┆┄┄ting the module.↲
↲
╞ max_chan╞ : The maximum of active logical channels.↲
╞ maxw_size : The maximum window size.↲
↲
╞ The needed creation parameters are:↲
↲
╞ Process parameters : please refer to subsection 4.2.1.↲
╞ Stack size : 1462 + max_chan * 36 (words).↲
╞ Priority : stdpriority (= -3) is recommended.↲
↲
╞ ┆84┆When the DTE module is created and starts up the following text ↓
┆19┆┆89┆┄┄will be printed on the console if test(4) is true:↲
↲
╞ >dte↲
╞ DATE 85.10.21. Version 14, env. 34.↲
╞ ┆a1┆┆e1┆ Max channels 5. Max. users 5.↲
↲
╞ ┆84┆This indicates the date (85.10.21) and version number (14) of the ↓
┆19┆┆89┆┄┄DTE module, the version number (34) of the internal dte environ┄↓
┆19┆┆89┆┄┄ment DTEENV. Furthermore the configuration parameters max_chan and ↓
┆19┆┆89┆┄┄max_users are printed.↲
↲
╞ ┆84┆When the Trace System is created the following text will be print┄↓
┆19┆┆89┆┄┄ed on the console↲
↲
╞ >dtetrace↲
╞ DTE TRACE Release 006 85.07.30↲
╞ ┆a1┆┆e1┆ Number of trace buf: 10↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
«index» formatlinie til RC manualer↲
┆14┆┆b3┆↲
┆14┆┆b3┆┆06┆- ┆0b┆ -↲
┆a1┆8.╞ SOURCE TEXT ORGANIZATION.↲
↲
╞ ┆84┆The source texts to the DTE System and the different compilation ↓
┆19┆┆89┆┄┄and list jobs are organized in several RC8000 library files (lib ↓
┆19┆┆89┆┄┄files) and normal RC8000 files. The following files constitute the ↓
┆19┆┆89┆┄┄DTE System:↲
↲
╞ dteinfoenv╞ ┆84┆version information, number and date↲
xpoolenv╞ ╞ external pool handler environment↲
╞ xdteenv ┆84┆external dte environment (constants and types ↓
┆19┆┆9d┆┄┄needed by a user)↲
╞ xtraceenv╞ ╞ external trace environment↲
╞ xx25env╞ ╞ external X.25 environment↲
╞ dtenetenv╞ ╞ comprimized netenv↲
↲
╞ libtdte<xx>╞ ┆84┆DTE source texts and external procedures (lib ↓
┆19┆┆9d┆┄┄file)↲
╞ libtx25╞ ╞ external X.25 procedures (lib file)↲
↲
╞ libjdte╞ ╞ ┆84┆compilation and list jobs for model 1 (lib ↓
┆19┆┆9d┆┄┄file)↲
╞ libjdte2╞ ╞ ┆84┆compilation and list jobs for model 2 (lib ↓
┆19┆┆9d┆┄┄file)↲
↲
╞ ┆84┆Besides these files the following CENTERNET files are needed for ↓
┆19┆┆89┆┄┄compilation of the DTE System:↲
↲
╞ netenv╞ ╞ general network environment↲
╞ cnnetenv╞ ╞ general CENTERNET environment↲
╞ xncpenv╞ ╞ external NCP environment↲
↲
╞ ┆84┆In figure 44 the connections between the source texts, the compi┄↓
┆19┆┆89┆┄┄la┄tion jobs, the binary files, the CRC16 job and the load file are ↓
┆19┆┆89┆┄┄shown.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 44: DTE System text and job connections.↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆The contents of the lib-files, the plib-files are shown in appen┄↓
┆19┆┆89┆┄┄dix E.↲
↲
╞ ┆84┆At boot file generation it is possible to decide whether the Trace ↓
┆19┆┆89┆┄┄System and/or the Test System shall be integrated in the dteboot ↓
┆19┆┆89┆┄┄file. These options are input to the jdtepunch job.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆14┆┆b3┆┆06┆- ┆0b┆ -↲
↲
↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆A. REFERENCES↲
↲
╞ (1) ┆a1┆Recommendation X.25↲
┆84┆CCITT, Yellow Book┆14┆┆b3┆┆06┆↲
╞ ┆84┆Services and Facilities, Terminal Equipment and Interfaces↲
╞ ┆84┆ Vol. III - Fascicle VIII.2.↲
╞ Geneva 1981.↲
↲
╞ (2) ┆a1┆Recommendation X.121↲
╞ CCITT, Yellow Book↲
╞ Data Communication Networks↲
╞ Transmission, Signalling and Switching, Network aspects,↲
╞ Maintenance, Administrative arrangements↲
╞ Vol. VIII - Fascicle VIII.3↲
Geneva 1981.↲
↲
╞ (3) RCSL No 991-10316↲
╞ ┆a1┆CENTERNET, DTE Module↲
╞ ┆a2┆┆e2┆┆a1┆Programming Guide, Rev. 3.00↲
╞ Per Høgh, October 1985.↲
↲
╞ (4) RCSL No 991-10315↲
╞ ┆a1┆CENTERNET, Network Control,↲
╞ ┆a1┆DTE LCP Specification Sheets, Rev. 2.00↲
╞ Per Høgh, October 1985.↲
↲
╞ (5) ┆84┆PAXNET↲
╞ ┆a1┆The User and LCP Interface of the Pool Handler↲
╞ ┆a1┆Reference Manual, Rev. 1.00↲
╞ Jørgen Linderoth, March 1983.↲
↲
╞ (6) DOKS NR. SP.TSSYS.15/2↲
╞ ┆a1┆Alarm-system↲
╞ ┆a1┆Systembeskrivelse for TS Timeoutmodulet↲
╞ Ole Ejby Reinau, May 1980.↲
↲
╞ (7) RCSL No 43-GL11870↲
╞ ┆a1┆RC3502 Snooper↲
╞ ┆a1┆User's Guide↲
╞ Valther Rasmussen, October 1982.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ (8) RCSL No 43-GL12166↲
╞ ┆a1┆CENTERNET, CNADAM↲
╞ ┆a1┆Reference Manual, Rev. 2.00↲
╞ Peter Holm, December 1983.↲
↲
╞ (9) RCSL No 52-AA1214↲
╞ ┆a1┆RC3546 HDLC Driver↲
╞ ┆a1┆Reference Manual↲
╞ Per Mondrup, December 1983.↲
↲
(10) RCSL No 43-GL11424↲
╞ ┆a1┆NCP Data Structures,↲
╞ ┆a1┆Reference Manual, Rev. 1.02↲
╞ Claus Houlberg Hansen, August 1981.↲
↲
(11) RCSL No 52-AA964↲
╞ ┆a1┆PASCAL80, Report↲
╞ Jørgen Staunstrup, January 1980.↲
↲
(12) RCSL No 42-i1539↲
╞ ┆a1┆PASCAL80, User's Guide↲
╞ Jan Bardino, October 1980.↲
↲
(13) RCSL No 42-i1542↲
╞ ┆a1┆RC3502 - PASCAL80, Reference Manual↲
╞ Bo Bagger Laursen, November 1980.↲
↲
(14) RCSL No 52-AA1072↲
╞ ┆a1┆RC3502 REAL TIME PASCAL↲
╞ ┆a1┆Extensions to the Reference Manual↲
╞ Bo Bagger Laursen, October 1981.↲
↲
(15) RCSL No 52-AA1056↲
╞ ┆a1┆RC3502 REAL TIME PASCAL↲
╞ ┆a1┆Character Input/Output Routines↲
╞ Bo Bagger Laursen, June 1981.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆B.╞ ENVIRONMENTS↲
↲
╞ ┆84┆In this appendix are the different RTP environments to the DTE ↓
┆19┆┆89┆┄┄System listed. Furthermore a lookup of necessary external ↓
┆19┆┆89┆┄┄environments is shown in B.1. In B.8 is an example (STDCONF) of ↓
┆19┆┆89┆┄┄the configuration environment shown.↲
↲
↲
┆b0┆┆a1┆B.1╞ External Environments↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆B.2╞ xdteenv↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆B.3╞ xx25env↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆B.4╞ xtraceenv↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆B.5╞ dteenv↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆B.6╞ dtebreakenv↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆B.7╞ hdlcenv↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆B.8╞ stdconf↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆C.╞ STATE/ACTION TABLES↲
↲
╞ ┆84┆In this appendix are the state/action tables for the dte_access ↓
┆19┆┆89┆┄┄(C.1), dte_lcnzero (C.2), and dte_chan (C.3) shown and a short ↓
┆19┆┆89┆┄┄description of each action is given.↓
↲
↲
┆b0┆┆a1┆C.1╞ dte_access↲
↲
╞ ┆84┆As mentioned in subsection 4.3.6 the dte_access process contains ↓
┆19┆┆89┆┄┄four state/action tables↲
↲
╞ ╞ - one for user dependent actions↲
╞ ╞ - one for stream dependent actions↲
╞ ╞ - one for internal stream dependent actions↲
╞ ╞ - one for stream independent actions.↲
↲
╞ ┆84┆Because of the connection between the tables stream dependent and ↓
┆19┆┆89┆┄┄internal stream dependent, one table (C.1.2) outline the two im┄↓
┆19┆┆89┆┄┄plemented state/action tables. Furthermore is the call request and ↓
┆19┆┆89┆┄┄incomming call events included in this table. The other two are ↓
┆19┆┆89┆┄┄shown as they are implemented.↲
↲
↲
┆b0┆┆a1┆C.1.1╞ User Dependent↲
↲
╞ __________________________________________________________________↲
╞ state free w_resc idle active↲
┆a1┆event╞ ╞ ╞ ╞ ╞ ╞ ╞ ↲
╞ call free╞ w_resc active active↲
╞ request↲
╞ ┆a1┆ not_conn ill_ureq call_init call_init ↲
wait free w_resc idle active↲
event↲
┆a1┆ not_conn queue_ebuf queue_ebuf queue_ebuf ↲
receive free idle idle active↲
general↲
┆a1┆ not_conn queue_gbuf queue_gbuf queue_gbuf ↲
↲
╞ Table 13: Process dte_access, user dependent state/action table.↲
↲
┆8c┆┄┆a9┆↓
╞ ┆a1┆Actions:↲
↲
↲
╞ ┆b0┆call_init╞ ╞ ┆f0┆: ┆84┆Check if the dte_state is ready, and a free ↓
┆19┆┆9f┆┆81┆┄stream awailable. If it is, start call set-↓
┆19┆┆9f┆┆81┆┄up phase by requesting a logical channel ↓
┆19┆┆9f┆┆81┆┄from the dte process.↲
↲
╞ ┆b0┆queue_ebuf╞ ┆f0┆: ┆84┆Queue the event buffer at the semaphore ↓
┆19┆┆9f┆┆81┆┄w_event_bsem. Then check if any event is ↓
┆19┆┆9f┆┆81┆┄lost and if so generate an event.↲
↲
╞ ┆b0┆queue_gbuf╞ ┆f0┆: ┆84┆Queue the input buffer at the semaphore ↓
┆19┆┆9f┆┆81┆┄general_bsem.↲
↲
╞ ┆b0┆ill_ureq╞ ╞ ┆f0┆: ┆84┆Return the message with result 'function not ↓
┆19┆┆9f┆┆81┆┄allowed' (fct_not_allw)↲
↲
╞ ┆b0┆not_conn╞ ╞ ┆f0┆: ┆84┆Return the message with result 'user un┄↓
┆19┆┆9f┆┆81┆┄known' (recv_unkw).↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆C.1.2╞ Stream Dependent↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆a1┆Actions:↲
↲
┆b0┆╞ queue_ureq╞ ┆f0┆: ┆84┆The message is signalled to the associated ↓
┆19┆┆9f┆┆81┆┄dte_chan process incarnation.↲
↲
╞ ┆b0┆call_accept╞ ┆f0┆: ┆84┆Depending of the intern_state either the ↓
┆19┆┆9f┆┆81┆┄message is signalled to the semaphore sus┄↓
┆19┆┆9f┆┆81┆┄pend_bsem or the call set-up phase is ended, ↓
┆19┆┆9f┆┆81┆┄including forwarding the message to the as┄↓
┆19┆┆9f┆┆81┆┄sociated dte_chan process incarnation.↲
↲
╞ ┆b0┆call_rejct╞ ┆f0┆: ┆84┆The stream is cleared and the message ↓
┆19┆┆9f┆┆81┆┄forwarded to the dte_chan process ↓
┆19┆┆9f┆┆81┆┄incarnation in order to clear the Virtual ↓
┆19┆┆9f┆┆81┆┄Call.↲
↲
╞ ┆b0┆user_clear╞ ┆f0┆: ┆84┆Depending of intern_state the message is ↓
┆19┆┆9f┆┆81┆┄either signal to the dte_chan process incar┄↓
┆19┆┆9f┆┆81┆┄nation or the semaphore suspend_bsem.↲
↲
╞ ┆b0┆chan_alloc╞ ┆f0┆: ┆84┆The logical channel has been allocated, so ↓
┆19┆┆9f┆┆81┆┄the stream is initialized.↲
↲
╞ ┆b0┆chan_clear╞ ┆f0┆: ┆84┆The logical channel has been allocated, but ↓
┆19┆┆9f┆┆81┆┄cleared by the dte_chan process incarnation. ↓
┆19┆┆9f┆┆81┆┄The stream is cleared in the interface ↓
┆19┆┆9f┆┆81┆┄(dte_access).↲
↲
╞ ┆b0┆xfer_event╞ ┆f0┆: ┆84┆A stream event is generated.↲
↲
╞ ┆b0┆clear_ch╞ ╞ ┆f0┆: ┆84┆The message is awaiting chan_start answer.↲
↲
╞ ┆b0┆clear_strm╞ ┆f0┆: ┆84┆The stream clearing phase is started.↲
↲
╞ ┆b0┆st_cleared╞ ┆f0┆: ┆84┆The stream clearing phase is ended.↲
↲
╞ ┆b0┆switch_mode╞ ┆f0┆: ┆84┆Switch input mode from dedicated to general.↲
↲
╞ ┆b0┆retn_notpr╞ ┆f0┆: ┆84┆Return the message with result ↓
┆19┆┆9f┆┆81┆┄not_processed.↲
↲
┆8c┆┄┆a9┆↓
╞ ┆b0┆ill_sreq╞ ╞ ┆f0┆: ┆84┆Return the message with result 'function not ↓
┆19┆┆9f┆┆81┆┄allowed' (fct_not_allw).↲
↲
╞ ┆b0┆unkw_req╞ ╞ ┆f0┆: ┆84┆Return the message with result 'illegal ope┄↓
┆19┆┆9f┆┆81┆┄ration' (ill_opcode).↲
↲
↲
┆b0┆┆a1┆C.1.3╞ Stream Independent↲
╱04002d440c00060000000003014e31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
┆a1┆┆e1┆╞ ____________________________________________________________________↲
state dte_ hdlc_ net_↲
dte_ready restart active down↲
┆a1┆┆e1┆ ┆a1┆event ↲
connect dte_ready dte_restart hdlc_active net_down↲
↲
┆a1┆ conn_user conn_user conn_user conn_user ↲
┆e1┆┆a1┆┆e1┆╞ disconnect dte_ready dte_restart hdlc_active net_down↲
↲
┆a1┆ disc_user disc_user disc_user disc_user ↲
inc call dte_ready dte_restart hdlc_active net_down↲
↲
┆a1┆ xfer_call rest_state rest_state rest_state ↲
restart_ dte_restart dte_restart hdlc_active net_down↲
start↲
┆a1┆ restart_dte restarted restarted restarted ↲
restart_end dte_ready dte_ready dte_ready dte_ready↲
↲
┆a1┆ restart_dte restart_dte restart_dte restart_dte↲
┆a1┆┆e1┆ inc_u_event dte_ready dte_restart hdlc_active net_down↲
↲
┆a1┆ xfer_u_event rest_state rest_state rest_state ↲
↲
╞ Table 15: Process dte_access, stream independent state/action table.↲
↲
╞ ┆a1┆Actions:↲
↲
╞ ┆b0┆conn_user╞ ╞ ┆f0┆: ┆84┆Find an empty user entry and connect the user.↲
↲
┆8c┆┄┆a6┆↓
╞ ┆b0┆disc_user╞ ╞ ┆f0┆: ┆84┆Disconnect the user.↲
↲
╞ ┆b0┆xfer_call╞ ╞ ┆f0┆: ┆84┆Find the requested user and a free stream. If ↓
┆19┆┆9f┆┆81┆┄ok transfer the incoming call to the user.↲
↲
╞ ┆b0┆restart_dte╞ ┆f0┆: ┆84┆Get the restart parameters and generate an user ↓
┆19┆┆9f┆┆81┆┄event. If necessary clear all streams.↲
↲
╞ ┆b0┆rest_state╞ ┆f0┆: ┆84┆Return message with result 'dte_restarted'.↲
↲
╞ ┆b0┆restarted╞ ╞ ┆f0┆: ┆84┆Nothing is performed.↲
↲
╞ ┆b0┆xfer_u_event╞ ┆f0┆: ┆84┆A user event is generated.↲
┆b0┆↲
↲
┆b0┆┆a1┆C.2╞ dte_lcnzero↲
↲
╞ ┆84┆As mentioned in subsection 4.5.6 the dte_lcnzero process contains ↓
┆19┆┆89┆┄┄one state/action table implemented as a state machine. This table ↓
┆19┆┆89┆┄┄is shown below and a short description of the actions is given ↓
┆19┆┆89┆┄┄too.↲
↲
════════════════════════════════════════════════════════════════════════
↓
state r1 r2 r4 r5 ↲
dte_ dte_ hdlc_ net_↲
┆a1┆┆e1┆ ┆a1┆event ready restart active down ↲
restart_indi r1 r1 r1 r5↲
┆a1┆┆e1┆ lcn = 0↲
╞ ┆a1┆ A10 A15 A15 A1↲
restart_conf r2 r1 r1 r5↲
lcn = 0↲
┆a1┆ A12 A15 A15 A1↲
diagnostic r1 r2 r4 r5↲
lcn = 0↲
┆a1┆ A13 A13 A13 A13↲
↲
↲
╞ _________________________________________________________↲
all other r1 r2 r4 r5↲
X.25 packets↲
┆a1┆ A1 A1 A1 A1↲
↲
↲
╞ _________________________________________________________↲
NC restart r2 r2 r4 r5↲
request↲
┆a1┆ A14 A0 A14 A2↲
hdlc_ r5 r5 r5 r4↲
connected↲
┆a1┆ A9 A9 A9 A17↲
hdlc_ r5 r5 r5 r5↲
disconnected↲
┆a1┆ A0 A5 A5 A9↲
timer t20 r5 r2 r4 r5↲
┆a1┆┆e1┆expired↲
┆a1┆ A9 A16 A16 A9↲
↲
╞ Table 16: Process dte_lcnzero, state/action table.↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014e31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆a1┆Actions:↲
↲
╞ ┆b0┆A0 ┆f0┆: Return message with result 'ok'↲
↲
╞ ┆b0┆A1 ┆f0┆: Return message to pool.↲
↲
╞ ┆b0┆A2 ┆f0┆: Return message with result 'rejected'.↲
↲
╞ ┆b0┆A5 ┆f0┆: ┆84┆Stop timer t20 (state := t_stop) and↲
╞ return message with result 'ok'↲
↲
╞ ┆b0┆A9 ┆f0┆: (* State table error *)↲
↲
╞ ┆b0┆A10┆f0┆: (* Restart indication received *)↲
┆84┆Inform the dte process, send restart con┄firmation to DCE ↓
┆19┆┆91┆┄┄and generate an NC event.↲
↲
╞ ┆b0┆A12┆f0┆: (* DCE local procedure error *)↲
┆84┆Send restart request to DCE, start timer t20 (state := ↓
┆19┆┆91┆┄┄t_run) and inform the dte process.↲
↲
╞ ┆b0┆A13┆f0┆: (* Diagnostic received *)↲
Generate an NC event and inform the dte process.↲
↲
╞ ┆b0┆A14┆f0┆: (* Restart requested by the DTE *)↲
┆84┆Send restart request to DCE, start timer t20 (state := ↓
┆19┆┆91┆┄┄t_run) and return message with result ok.↲
↲
╞ ┆b0┆A15┆f0┆: (* Restart phase ended *)↲
┆84┆Stop timer t20 (state := t_stop), inform the dte process ↓
┆19┆┆91┆┄┄and generate an NC event.↲
↲
╞ ┆b0┆A16┆f0┆: (* Timer t20 has expired *)↲
┆84┆Send restart request to the DCE start timer t20 (state := ↓
┆19┆┆91┆┄┄t_run) and inform the dte process.↲
↲
╞ ┆b0┆A17┆f0┆: (* hdlc line connected *)↲
╞ ┆84┆Start timer t20 (state := t_run) and return message with ↓
┆19┆┆91┆┄┄result ok.↲
↲
↲
┆8c┆┄┆a9┆↓
┆b0┆┆a1┆C.3╞ dte_chan↲
↲
╞ ┆84┆As mentioned in subsection 4.6.6 the dte_chan process contains one ↓
┆19┆┆89┆┄┄state/action table, implemented as a state machine. This table is ↓
┆19┆┆89┆┄┄shown below as 5 subtables and a short description of each action ↓
┆19┆┆89┆┄┄is given too. To get a clearer view of the state transitions 4 ↓
┆19┆┆89┆┄┄figures (fig. 45 to fig. 48) outlines the call set-up/clear phase, ↓
┆19┆┆89┆┄┄the data phase and the reset phase.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆84┆All actions are grouped depending of the overall type of action to ↓
┆19┆┆89┆┄┄be performed. ↓
┆19┆┆89┆┄┄Six groups have been identified:↲
↲
╞ A0-A9 : returnal/discard of message/answer.↲
A10-A19: call set-up phase↲
A20-A29: clear phase↲
A30-A39: normal data transfer↲
A40-A49: reset phase↲
A50-A54: special actions↲
↲
╞ ┆a1┆Actions:↲
↲
╞ ┆b0┆A0 ┆f0┆: Dummy.↲
↲
╞ ┆b0┆A1 ┆f0┆: ┆84┆Discard small or big packet by returning buffer to pool.↲
↲
╞ ┆b0┆A2 ┆f0┆: ┆84┆Discard big packet by returning buffer to pool.↲
↲
╞ ┆b0┆A4 ┆f0┆: ┆84┆(* State table error *)↲
╞ ┆84┆Trace event.↲
↲
╞ ┆b0┆A5 ┆f0┆: Return message with result 'ok'↲
↲
╞ ┆b0┆A6 ┆f0┆: ┆84┆Return message with result 'not_processed'.↲
↲
╞ ┆b0┆A8 ┆f0┆: ┆84┆Return message with result 'fct_not_allw'.↲
↲
╞ ┆b0┆A10┆f0┆: ┆84┆(* Incomming call received *)↲
╞ ┆84┆The packet is checked, tables are updated, data are moved to ↓
┆19┆┆8e┆┄┄a general input buffer and this buffer is signalled to the ↓
┆19┆┆8e┆┄┄dte_access process. If the check fails, a CLEAR REQUEST pac┄↓
┆19┆┆8e┆┄┄ket is transmitted to the DCE, and an NC event is generated.↲
↲
╞ ┆b0┆A11┆f0┆: (* Call request is received from the user *)↲
╞ ┆84┆The message is checked, tables are updated, and an X.25 CALL ↓
┆19┆┆8e┆┄┄REQUEST packet is build up and transmitted to the DCE. If any ↓
┆19┆┆8e┆┄┄thing went wrong the user is informed by returnal of the buf┄↓
┆19┆┆8e┆┄┄fer and a stream event.↲
↲
┆8c┆┄┆a8┆↓
╞ ┆b0┆A12┆f0┆: (* The user has rejected the incomming call *)↲
╞ ┆84┆A CLEAR REQUEST packet is transmitted to the DCE and table ↓
┆19┆┆8e┆┄┄chan_rec is updated. An NC event is genereated.↲
↲
╞ ┆b0┆A13┆f0┆: ┆84┆(* The Virtual Call has been cleared before the user has ↓
┆19┆┆8e┆┆81┆┄responded *)↲
╞ ┆84┆If the user is accepting the call set-up, the message is ↓
┆19┆┆8e┆┄┄returned with result 'not_processed'. All internal messages ↓
┆19┆┆8e┆┄┄are released.↲
↲
╞ ┆b0┆A16┆f0┆: ┆84┆(* The call set-up is accepted by the DCE. A call connected ↓
┆19┆┆8e┆┆81┆┄packet is received *)↲
╞ ┆84┆The CALL CONNECTED data is moved to the user dte_call_req ↓
┆19┆┆8e┆┄┄message and returned to the user. An NC event is generated ↓
┆19┆┆8e┆┄┄and tables, pool, and timers are updated. If dedicated input ↓
┆19┆┆8e┆┄┄is used, the state machine is prepared for sending an RNR ↓
┆19┆┆8e┆┄┄packet.↲
↲
┆b0┆╞ A17┆f0┆: ┆84┆(* The call set-up is accepted by the user. A call_accept ↓
┆19┆┆8e┆┆81┆┄message is received *)↲
╞ ┆84┆A CALL ACCEPTED packet is transmitted to the DCE. An NC event ↓
┆19┆┆8e┆┄┄is generated, and tables, pool, and timers are updated.↲
╞ ┆84┆If dedicated input is used, the state machine is prepared for ↓
┆19┆┆8e┆┄┄sending an RNR packet.↲
↲
╞ ┆b0┆A18┆f0┆: ┆84┆(* Timeout t11m: the user has not answered a Virtual Call ↓
┆19┆┆8e┆┆81┆┄set-up request *)↲
╞ ┆84┆The logical channel is cleared by transmitting a CLEAR ↓
┆19┆┆8e┆┄┄REQUEST packet to the DCE and informing the user through the ↓
┆19┆┆8e┆┄┄dte_access process. An NC event is generated.↲
↲
╞ ┆b0┆A19┆f0┆: ┆84┆(* Timeout t21: the DCE has not answered a call request pac┄↓
┆19┆┆8e┆┆81┆┄ket *)↲
╞ ┆84┆The logical channel is cleared by transmitting a CLEAR RE┄↓
┆19┆┆8e┆┄┄QUEST packet to the DCE and informing the user through the ↓
┆19┆┆8e┆┄┄dte_access process. An NC event is generated.↲
↲
╞ ┆b0┆A21┆f0┆: (* DCE local procedure error in state xidle *)↲
╞ ┆84┆A CLEAR REQUEST packet is transmitted to the DCE.↲
↲
┆8c┆┄┆a8┆↓
╞ ┆b0┆A22┆f0┆: (* A clear indication packet is received in state xidle *)↲
╞ ┆84┆A CLEAR CONFIRMATION packet is transmitted to the DCE, and ↓
┆19┆┆8e┆┄┄the internal stop procedure is initiated.↲
↲
┆b0┆╞ A23┆f0┆: (* A clear indication packet is received *)↲
╞ ┆84┆A CLEAR CONFIRMATION packet is transmitted to the DCE. The ↓
┆19┆┆8e┆┄┄user is informed through the dte_access process. All user ↓
┆19┆┆8e┆┄┄buffers are returned with result 'not_processed'. An NC event ↓
┆19┆┆8e┆┄┄is generated and the internal stop procedure is initiated.↲
↲
┆b0┆╞ A24┆f0┆: (* DCE local procedure error *)↲
╞ ┆84┆A CLEAR REQUEST packet is transmitted to the DCE. The user is ↓
┆19┆┆8e┆┄┄informed through the dte_access process. All user buffers are ↓
┆19┆┆8e┆┄┄returned with result 'not_processed'. An NC event is gene┄↓
┆19┆┆8e┆┄┄rated.↲
↲
┆b0┆╞ A25┆f0┆: (* A clear request message is received from the user *)↲
╞ ┆84┆A CLEAR REQUEST packet is transmitted to the DCE. All user ↓
┆19┆┆8e┆┄┄buffers are returned, and an NC event is generated.↲
↲
┆b0┆╞ A26┆f0┆: ┆84┆(* Timeout t23: the DCE has not answered a clear request ↓
┆19┆┆8e┆┆81┆┄packet *)↲
╞ ┆84┆A CLEAR REQUEST packet is transmitted to the DCE. If state is ↓
┆19┆┆8e┆┄┄xdteclear all remaining user buffers are returned, and the ↓
┆19┆┆8e┆┄┄clearing phase of the stream (interface to user) is finished ↓
┆19┆┆8e┆┄┄by informing the dte_access process.↲
↲
┆b0┆╞ A27┆f0┆: ┆84┆(* A clear indication or confirmation packet is received in ↓
┆19┆┆8e┆┆81┆┄state xret_clear *)↲
╞ ┆84┆An NC event is generated and the internal stop procedure is ↓
┆19┆┆8e┆┄┄initiated.↲
↲
┆b0┆╞ A29┆f0┆: ┆84┆(* A clear indication or confirmation packet is received as ↓
┆19┆┆8e┆┆81┆┄an answer on a clear request packet *)↲
╞ ┆84┆All pending user buffers are returned and the clearing phase ↓
┆19┆┆8e┆┄┄of the stream (interface to user) is finished by informing ↓
┆19┆┆8e┆┄┄the dte_access process. The internal stop procedure is ↓
┆19┆┆8e┆┄┄initiated.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ ┆b0┆A30┆f0┆: (* A data packet is received *)↲
╞ ┆84┆The sequence counters (P(R), P(S)) are checked. If not ok an ↓
┆19┆┆8e┆┄┄reset phase is initiated by sending a RESET REQUEST packet to ↓
┆19┆┆8e┆┄┄the DCE.↲
↲
╞ ┆84┆If ok, the data is moved to a user buffer (either general or ↓
┆19┆┆8e┆┄┄dedicated input depending on chan_rec.rcv_buf_type, receive ↓
┆19┆┆8e┆┄┄buffer type). If the P(R) acknowledged any send_data message ↓
┆19┆┆8e┆┄┄these are returned if possible. If the window has been moved, ↓
┆19┆┆8e┆┄┄data can be sent if any. An RR packet is transmitted to the ↓
┆19┆┆8e┆┄┄DCE if necessary. The timer t30 is updated.↲
↲
┆b0┆╞ A31┆f0┆: (* An interrupt packet is received *)↲
╞ ┆84┆The interrupt data is moved to a user general input buffer, ↓
┆19┆┆8e┆┄┄which is returned to the user, and an INTERRUPT CONFIRMATION ↓
┆19┆┆8e┆┄┄packet is transmitted to the DCE.↲
↲
┆b0┆╞ A32┆f0┆: ┆84┆(* A data packet is received in a state, where the DTE is not ↓
┆19┆┆8e┆┆81┆┄ready *)↲
╞ ┆84┆The sequence counters (P(R), P(S)) are checked. If not ok an ↓
┆19┆┆8e┆┄┄reset phase is initiated by sending a RESET REQUEST packet to ↓
┆19┆┆8e┆┄┄the DCE.↲
↲
╞ ┆84┆If ok, queue the packet if the bit data_lost in status_word ↓
┆19┆┆8e┆┄┄is not already set. If it is, discard the packet.↲
↲
╞ ┆84┆If the P(R) acknowledged any send_data message these are ↓
┆19┆┆8e┆┄┄returned if possible.↲
↲
┆b0┆╞ A33┆f0┆: (* An rr or rnr is received *)↲
╞ ┆84┆The sequence counter P(R) is checked. If not ok an reset ↓
┆19┆┆8e┆┄┄phase is initiated by sending a RESET REQUEST packet to the ↓
┆19┆┆8e┆┄┄DCE. If the window has been moved, data can be sent if any. ↓
┆19┆┆8e┆┄┄If the P(R) acknowledged any send_data messages these are ↓
┆19┆┆8e┆┄┄returned if possible.↲
↲
┆b0┆╞ A34┆f0┆: (* Internal event: window open *)↲
╞ ┆84┆Enough dedicated input buffers has been supplied by the user ↓
════════════════════════════════════════════════════════════════════════
↓
┆19┆┆8e┆┄┄to set the Virtual Call in dte ready, by transmitting an RR ↓
┆19┆┆8e┆┄┄packet to the DCE. If any X.25 DATA packets are queued, ↓
┆19┆┆8e┆┄┄'receive' these and return the data to the user in a ↓
┆19┆┆8e┆┄┄dedicated input buffer.↲
↲
┆b0┆╞ A35┆f0┆: (* A send_data message is received *)↲
╞ ┆84┆The size of the message is checked, so an X.25 header can be ↓
┆19┆┆8e┆┄┄in front of the user data. If ok an X.25 DATA packet is ↓
┆19┆┆8e┆┄┄transmitted to the DCE if internal resources available and ↓
┆19┆┆8e┆┄┄window open. If not possible to sent DATA packet it is queue ↓
┆19┆┆8e┆┄┄at a semaphore.↲
↲
┆b0┆╞ A36┆f0┆: (* A send_interrupt message is received *)↲
╞ ┆84┆The size of the message is checked, so an X.25 header can be ↓
┆19┆┆8e┆┄┄in front of the user data. If ok an X.25 INTERRUPT packet is ↓
┆19┆┆8e┆┄┄transmitted to the DCE.↲
↲
┆b0┆╞ A37┆f0┆: (* Timeout t30: idle timer *)↲
╞ ┆84┆An RR packet is transmitted to the DCE.↲
↲
┆b0┆╞ A38┆f0┆: (* An interrupt confirmation packet is received *)↲
╞ ┆84┆The now acknowledged interrupt is returned to the user. If ↓
┆19┆┆8e┆┄┄any dte_send_interrupt is pending the first is transmitted to ↓
┆19┆┆8e┆┄┄the DCE as an X.25 INTERRUPT packet.↲
↲
┆b0┆╞ A40┆f0┆: (* An reset request message is received *)↲
╞ ┆84┆An reset phase is initiated by transmitting an RESET REQUEST ↓
┆19┆┆8e┆┄┄packet to the DCE. All user buffers are returned.↲
↲
┆b0┆╞ A41┆f0┆: ┆84┆(* An reset indication packet is received in state wsync, ↓
┆19┆┆8e┆┆81┆┄ndce_wsync *)↲
╞ ┆84┆An RESET CONFIRMATION packet is transmitted to the DCE. All ↓
┆19┆┆8e┆┄┄user buffers are returned.↲
↲
┆b0┆╞ A42┆f0┆: (* Timeout t12m: DCE reset timeout *)↲
╞ ┆84┆An RESET CONFIRMATION packet is transmitted to the DCE. If ↓
┆19┆┆8e┆┄┄dedicated input is used, the state machine is prepared for ↓
┆19┆┆8e┆┄┄sending an RNR packet.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ A43┆f0┆: (* A sync message is received *)↲
╞ ┆84┆The message is queued until an RESET CONFIRMATION packet is ↓
┆19┆┆8e┆┄┄received.↲
↲
╞ ┆b0┆A44┆f0┆: (* A sync message is received *)↲
╞ ┆84┆The reset phase is ended by sending a RESET CONFIRMATION ↓
┆19┆┆8e┆┄┄packet to the DCE and returning the dte_sync_stream message ↓
┆19┆┆8e┆┄┄to the user. If dedicated input is used, the state machine is ↓
┆19┆┆8e┆┄┄prepared for sending an RNR packet.↲
↲
┆b0┆╞ A45┆f0┆: (* An reset indication packet is received *)↲
╞ ┆84┆The user is informed through the dte_access process and all ↓
┆19┆┆8e┆┄┄user buffers are returned with result 'not_processed_. Timer ↓
┆19┆┆8e┆┄┄t12m is started.↲
↲
┆b0┆╞ A46┆f0┆: ┆84┆(* An reset indication packet is received in state ↓
┆19┆┆8e┆┆81┆┄ndte_wsync, ndctewsync *)↲
╞ ┆84┆An RESET CONFIRMATION packet is transmitted to the DCE. All ↓
┆19┆┆8e┆┄┄user buffers are returned, and any X.25 DATA packets queued ↓
┆19┆┆8e┆┄┄are discarded.↲
╞ ┆84┆The state machine is prepared for sending an RNR packet.↲
↲
┆b0┆╞ A47┆f0┆: ┆84┆(* An reset indication or confirmation packet is received *)↲
╞ ┆84┆The reset phase is ended. Return a possible dte_reset_req ↓
┆19┆┆8e┆┄┄message. If dedicated input is used and not enough dedicated ↓
┆19┆┆8e┆┄┄input buffers are supplied by the user, the state machine is ↓
┆19┆┆8e┆┄┄prepared for sending an RNR packet.↲
↲
┆b0┆╞ A48┆f0┆: ┆84┆(* Timeout t22: the DCE has not answered an reset request ↓
┆19┆┆8e┆┆81┆┄packet *)↲
╞ ┆84┆An RESET REQUEST packet is transmitted to the DCE, and timer ↓
┆19┆┆8e┆┄┄t22 is started.↲
↲
┆b0┆╞ A49┆f0┆: (* DCE local procedure error *)↲
╞ ┆84┆All user buffers are returned. If state is xreset or any ↓
┆19┆┆8e┆┄┄xxx_wsync the user is not informed. Otherwise the user is ↓
┆19┆┆8e┆┄┄informed through the dte_access process. Timer t22 is ↓
┆19┆┆8e┆┄┄started.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ A50┆f0┆: ┆84┆(* A send data message received in any state with dte not ↓
┆19┆┆8e┆┆81┆┄ready *)↲
╞ ┆84┆The message size is checked, so an X.25 header can be in front ↓
┆19┆┆8e┆┄┄of the user data. If ok queue the message at a semaphore.↲
↲
┆b0┆╞ A51┆f0┆: ┆84┆(* A send interrupt message is received in a state with an ↓
┆19┆┆8e┆┆81┆┄unacknowledged X.25 interrupt *)↲
╞ ┆84┆The message is queued at a semaphore.↲
↲
┆b0┆╞ A52┆f0┆: (* Timeout t31: data lost timer *)↲
╞ ┆84┆Discard any queued X.25 DATA packets and if any is discarded ↓
┆19┆┆8e┆┄┄set the bit data_lost in the status_word.↲
↲
┆b0┆╞ A53┆f0┆: (* Internal event: xdata ┆a1┆d┆e1┆te ┆a1┆n┆e1┆ot ┆a1┆r┆e1┆eady *)↲
╞ ┆84┆An RNR packet is transmitted to the DCE.↲
↲
┆b0┆╞ A54┆f0┆: (* A change input mode message is received *)↲
╞ ┆84┆All dedicated input buffers are returned with result ↓
┆19┆┆8e┆┄┄'not_processed', and an RR packet is transmitted to the DCE.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 45: ┆84┆Process dte_chan, state transition graph for the call ↓
┆19┆┆94┆┄┄set-up and clear phase.↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 46: ┆84┆Process dte_chan, state transition graph for the data ↓
┆19┆┆94┆┄┄phase.↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 47: ┆84┆Process dte_chan, state transition graph for the reset ↓
┆19┆┆94┆┄┄phase, part 1.↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
┆81┆↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 48: ┆84┆Process dte_chan, state transition graph for the reset ↓
┆19┆┆94┆┄┄phase, part 2.↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆D.╞ TRACE AND TEST DESCRIPTION↲
↲
╞ ┆84┆In this appendix examples of trace output (D.1) and internal ↓
┆19┆┆89┆┄┄testoutput (D.3) is shown. Furthermore are the text strings used ↓
┆19┆┆89┆┄┄in writing the internal testoutput on the console described.↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆D.1 ╞ Trace Example↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆D.2╞ Testoutput Conversion↲
↲
╞ ┆84┆As mentioned in subsection 6.2.4 the format of the printed ↓
┆19┆┆89┆┄┄testoutput line for the processes dte_lcnzero and dte_chan depends ↓
┆19┆┆89┆┄┄of the testrecord type (kind).↲
╞ ┆84┆In table 18 these dependants are outlined.↲
↲
╞ dte_lcnzero print line:↲
↲
╞ ┆b0┆<time> <kind> <dte state> <field1> <field2> <field3> <aux>↲
↲
╞ dte_chan print line:↲
↲
╞ ┆b0┆<time> <kind> <state> <c_active> <field5>↲
╞ ┆b0┆<dec.field1> <hex.field1> <dec.field2> <hex.field2>↲
╞ ┆b0┆<dec.field3> <hex.field3> <dec.field4> <hex.field4>↲
╞ ┆b0┆<aux>↲
↲
╱04002d440c00060000000003015031400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
════════════════════════════════════════════════════════════════════════
↓
↲
╞ ______________________________________________________________________↲
╞ ╞ ┆82┆text┆81┆ kind ┆82┆<aux>┆81┆↲
╞ ┆a1┆ ╞ no ╞ ↲
╞ dte_lcnzero ┆a1┆ ┆a1┆x25-er 0 <packet_id> <decode result> ↲
╞ ╞ ┆a1┆ ┆a1┆a-lcn0 1 ↲
╞ ╞ ┆a1┆ ┆a1┆timer 2 <t20 state> ↲
╞ ╞ ┆a1┆ ┆a1┆ev/ac 3 <packet_id><event><action><t20 state>↲
╞ ╞ ┆a1┆ ┆a1┆unknw 4 ↲
╞ ┆a1┆╞ ┆a1┆sup-er 5 ↲
╞ dte_chan ┆a1┆ ┆a1┆u-dedi 0 ↲
╞ ╞ ┆a1┆ ┆a1┆lcp-op 2 ↲
╞ ╞ ┆a1┆ ┆a1┆unkw-m 3 ↲
╞ ╞ ┆a1┆ ┆a1┆a-chan 4 ↲
╞ ╞ ┆a1┆ ┆a1┆a-hrec 6 <packet_id> <decode result> ↲
╞ ╞ ┆a1┆ ┆a1┆a-hxmit 7 ↲
╞ ╞ ┆a1┆ ┆a1┆supmes 8 ↲
╞ ╞ ┆a1┆ ┆a1┆timer 9 <timer state> ↲
╞ ╞ ┆a1┆ ┆a1┆unkw-a 10 ↲
╞ ╞ ┆a1┆ ┆a1┆c-stop 11 <stop cause> ↲
╞ ╞ ┆a1┆ ┆a1┆c-init 12 ↲
╞ ╞ ┆a1┆ ┆a1┆ev/ac 13 <event> <action> ↲
┆a1┆╞ ┆a1┆CONT. 15 ↲
↲
╱04002d440c00060000000003014b31400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
╱04002d440c00060000000003015031400000000000000000000000000000000000000000000000000a141e28323c464b555f69737d8791ff04╱
↓
╞ Table 18: ┆84┆Print format for testoutput from the processes ↓
┆19┆┆93┆┄┄dte_lcnzero and dte_chan.↲
↲
↲
┆b0┆╞ ┆a1┆parameter <dte state> in dte and dte_lcnzero testoutput:↲
↲
╞ READY╞ : ┆84┆the DTE is in ready state, i.e. r1 according to the ↓
┆19┆┆95┆┄┄X.25 Recommendation (ref. (1)).↲
↲
╞ RESTART╞ : ┆84┆the DTE is in a restart phase, i.e. r2 according to ↓
┆19┆┆95┆┄┄the X.25 Recommendation (ref. (1)).↲
↲
════════════════════════════════════════════════════════════════════════
↓
╞ H-ACTIVE╞ : ┆84┆the hdlc line is connected, but level 3 has not yet ↓
┆19┆┆95┆┄┄exchanged restart packets.↲
↲
╞ NET DOWN╞ : ┆84┆the hdlc line is disconnected.↲
↲
┆b0┆╞ ┆a1┆parameter <packet-id> in dte_lcnzero and dte_chan:↲
↲
╞ DATA╞ : DCE data packet↲
╞ CALL╞ : incomming call packet↲
╞ CALL-A╞ : call connected packet↲
╞ CLEAR╞ : clear indication packet↲
╞ CLEAR-C╞ : DCE clear confirmation packet↲
╞ RESET╞ : reset indication packet↲
╞ RESET-C╞ : DCE reset confirmation packet↲
╞ INT╞ : DCE interrupt packet↲
╞ INT-C╞ : DCE interrupt confirmation packet↲
╞ DIAG╞ : Diagnostic packet↲
╞ RR╞ : DCE rr (modulo 8) packet↲
╞ RNR╞ : DCE rnr (modulo 8) packet↲
╞ REJ╞ : DTE rej (modulo 8) packet↲
╞ RESTART╞ : restart indication packet↲
╞ RESTA-C╞ : DCE restart confirmation packet↲
╞ ???????╞ : unknown packet↲
↲
┆b0┆╞ ┆a1┆parameter <decode result> in dte_lcnzero and dte_chan:↲
↲
╞ ok╞ : the packet decoding was performed without error↲
╞ lgth-e╞ : the packet is shorter than 2 octets↲
╞ form-e╞ : error in the general format identifier↲
╞ qbit-e╞ : the Q-bit is not allowed in call packets↲
╞ i-chan╞ : ┆84┆a restart, restart confirmation or diagnostic packet ↓
┆19┆┆95┆┄┄on a channel different from zero.↲
╞ diagna╞ : the diagnostic packet is not allowed↲
╞ rej-na╞ : the rej packet is not allowed from the DCE.↲
╞ unk-id╞ : ┆84┆the packet type is unknown or the packet length is ↓
┆19┆┆95┆┄┄shorter than 3 octets.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ┆a1┆parameter <timer state> in dte_lcnzero and dte_chan:↲
↲
╞ run╞ : the timer is active↲
╞ stop╞ : the timer is stopped↲
╞ updt╞ : ┆84┆the timer will be updated (started) as soon as ↓
┆19┆┆95┆┄┄resources are available.↲
↲
┆b0┆╞ ┆a1┆parameter <event> in dte_lcnzero:↲
↲
╞ rest-xt╞ : restart indication received from the network↲
╞ rest-xc╞ : ┆84┆restart confirmation received from the network↲
╞ x-diag╞ : diagnostic packet received from the network↲
╞ r-buf╞ : ┆84┆buffer request message returned from the dte_pool ↓
┆19┆┆95┆┄┄process↲
╞ rest-sr╞ : restart request received from the dte process↲
╞ c-hdlc╞ : hdlc connected indication received↲
╞ d-hdlc╞ : hdlc disconnected indication received↲
╞ t20-exp╞ : timer t20 expired↲
↲
┆b0┆╞ ┆a1┆parameter <state> in dte_chan:↲
↲
╞ ┆84┆The texts printed all equal those described in subsection 4.6.2.↲
↲
┆b0┆╞ ┆a1┆parameter <c_active> and <send_rnr> in dte_chan:↲
↲
╞ T╞ : true↲
╞ F╞ : false↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆╞ ┆a1┆parameter <stop cause> in dte_chan:↲
↲
╞ dtecl╞ : DTE initated clearing↲
╞ dceer╞ : ┆84┆clearing initiated because of an DCE error in call ↓
┆19┆┆95┆┄┄set-up↲
╞ cacce╞ : error in generation of an call accepted packet↲
╞ uterm╞ : user initiated clearing↲
╞ dcecl╞ : DCE clearing in state xidle↲
╞ calle╞ : error in generation of an call request packet↲
╞ incrj╞ : incomming call rejected↲
╞ srest╞ : restart indicated by the dte process↲
╞ timeo╞ : timeout in xdteclear state↲
╞ ruser╞ : remote user initiated clearing↲
╞ ?????╞ : unknown result↲
↲
┆b0┆╞ ┆a1┆parameter <event> in dte_chan:↲
↲
╞ ┆84┆The texts equal those in the state/action tables in appendix C.3.↲
↲
╞ w-open╞ : the X.25 window has been moved↲
╞ enghres╞ : enough buffers have been supplied by the user↲
╞ callreq╞ : call request message from the user↲
╞ inc-acp╞ : incomming call accepted by the user↲
╞ inc-rej╞ : incomming call rejected↲
╞ s-data╞ : send data message from the user↲
╞ s-intrp╞ : send interrupt message from the user↲
╞ ci-mode╞ : change input mode message from the user↲
╞ clr-req╞ : clear request message from the user↲
╞ sync╞ : synchronize stream message from the user↲
╞ t11╞ : timer t11m has expired↲
╞ t12╞ : timer t12m has expired↲
╞ t21 : timer t21 has expired↲
╞ t22╞ : timer t22 has expired↲
╞ t23╞ : timer t23 has expired↲
╞ t30╞ : timer t30 has expired↲
╞ t31╞ : timer t31 has expired↲
════════════════════════════════════════════════════════════════════════
↓
╞ xinccal╞ : X.25 incomming call received↲
╞ xcalcon╞ : X.25 call connected packet received↲
╞ xclear╞ : X.25 clear indication received↲
╞ xclr-co╞ : X.25 clear confirmation packet received↲
╞ xdatrnr╞ : internal event: xdata dte not ready↲
╞ xdata╞ : X.25 data packet received↲
╞ xint╞ : X.25 interrupt packet received↲
╞ xint-co╞ : X.25 interrupt confirmation packet received↲
╞ xrr╞ : X.25 rr packet received↲
╞ xrnr╞ : X.25 rnr packet received↲
╞ xreset╞ : X.25 reset indication received↲
╞ xresetc╞ : X.25 reset confirmation packet received↲
╞ others╞ : other undefined or illegal X.25 packet received↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆D.3╞ Testoutput Examples↲
↲
┆a1┆┆b0┆D.3.1╞ Process dte↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆D.3.2╞ Process dte_chan_001↲
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆E.╞ CONTENTS OF LIBRARIES↲
↲
╞ ┆84┆In this appendix are the contents of the different DTE libraries ↓
┆19┆┆89┆┄┄shown. In E.1 the libraries operated on by the fp utility ┆b0┆lib ↓
┆19┆┆89┆┆81┆┆82┆┆f0┆(source libraries) and in E.2 those operated on by the fp ↓
┆19┆┆89┆┆81┆┄utilities ┆b0┆pliblookup┆f0┆, ┆b0┆plibinsert┆f0┆, ┆b0┆plibextract ┆f0┆and ┆b0┆plibdelete ↓
┆19┆┆89┆┆85┆┆82┆┆f0┆(binary libraries).↲
↲
↲
┆b0┆┆a1┆E.1╞ Lib-Files↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆E.2╞ Plib-Files↲
════════════════════════════════════════════════════════════════════════
↓
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆F.╞ COMPILATION EXAMPLES↲
↲
╞ ┆84┆In this appendix four compilation examples are shown. In F.1 is ↓
┆19┆┆89┆┄┄the operator dialogue during an update of an existing binary dte ↓
┆19┆┆89┆┄┄shown. In F.2 is the generation of the X.25 procedure library ↓
┆19┆┆89┆┄┄shown and in F.3 an update of the same library. The trace system ↓
┆19┆┆89┆┄┄generation is shown in F.4. All operator operations are indicated ↓
┆19┆┆89┆┄┄by block faced types.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆F.1╞ Update of an Existing Binary dte.↲
┆81┆↲
╞ ┆b0┆lib set.libjdte jdtegen↲
↲
╞ end 38↲
╞ ┆b0┆i jdtegen↲
╞ *************** CENTERNET DTE MODULE COMPILATION ***************↲
type FILE NAME of SOURCE DTE : ┆b0┆libtdte14↲
╞ ┆81┆-----------------------------------------↲
╞ compilation of DTE supervisor type 1,yes ↲
╞ compilation of DTE access type 2.yes↲
╞ compilation of DTE channel p. type 3.yes↲
╞ compilation of DTE lcn zero type 4.yes↲
╞ compilation of hrec type 5.yes↲
╞ compilation of DTE poolhandler type 6.yes↲
╞ in one line ended with <cr>↲
╞ ┆b0┆5.yes↲
╞ Type name of DTE CONFIGURATION file↲
╞ standard file : type stdconf↲
╞ ┆b0┆stdconf↲
╞ Type yes if listning of DTE configuration file↲
is wanted ELSE no !!↲
╞ ┆b0┆no↲
↲
╞ information: segm pr. buf optimized: 34↲
╞ end↲
╞ UPDATE of an EXISTING or NEW binary DTE ????↲
╞ Type yes or no : ┆b0┆yes↲
╞ Type NAME of EXISTING or NEW binary DTE : ┆b0┆bdte20↲
dte hrec compilation↲
╞ dte hrec procwess generated↲
╞ binary dte updated↲
╞ ***lookup tempdte unknown↲
╞ dte generation ended↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆F.2╞ Generation of the X.25 Procedure Library.↲
↲
╞ ┆b0┆lib set.libjdte jx25lib↲
↲
╞ end 38↲
┆b0┆╞ i jx25lib↲
╞ ********** CENTERNET EXTERNAL X25 LIBRARY GENERATION **********↲
╞ type FILE NAME of SOURCE X.25 : ┆b0┆libx25↲
╞ fastmove: a temporary output file created on disc↲
↲
╞ end 38↲
╞ edit begin.↲
╞ ; (**** check x25 facilities ****)↲
╞ ; (**** check faci spec ****)↲
╞ ; (**** procedure code x25 ****)↲
╞ ; (**** procedure decode x25 ****)↲
; (**** init x25 facility check ****)↲
╞ ; (**** init window ****)↲
╞ ; (**** pack address ****)↲
╞ ; (**** unpack address ****)↲
╞ . (**** procedure w_algorithm ****)↲
↲
╞ 1136 line, end document.↲
╞ edit end.↲
x25 library generation↲
╞ x25 library generated↲
╞ x25 external procedure library compilation ended↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆F.3╞ Update of the X.25 Procedure Library.↲
↲
╞ ┆b0┆lib set.libjdte jx25proc↲
↲
╞ end 38↲
╞ ┆b0┆i jx25proc↲
╞ ********** CENTERNET X25 External Procedure Compilation **********↲
type FILE NAME of SOURCE X.25↲
╞ ended with a æ ┆b0┆: libtx25æ↲
╞ type NAME of EXTERNAL PROCEDURE,↲
╞ ended with a æ ┆b0┆: packadræ↲
type yes if LISTNING of source else no↲
╞ ┆b0┆no↲
↲
╞ end 38↲
╞ x25 external procedure compilation↲
╞ x25 library updated↲
╞ x25 procedure compilation ended↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆F.4╞ Generation of the Trace System.↲
↲
╞ ┆b0┆lib set.libjdte jdtetrace↲
↲
╞ end 38↲
╞ ┆b0┆i jdtetrace↲
╞ *********** CENTERNET DTE TRACE SYSTEM COMPILATION ***********↲
╞ type FILE NAME of SOURCE DTE TRACE ┆b0┆: libtdte14↲
╞ ┆81┆----------------------------------------------↲
╞ compilation of DTE trace type 1.yes↲
╞ compilation of DTE outtrace type 2.yes↲
in one line ended with <cr>↲
╞ ┆b0┆1.yes 2.yes↲
╞ UPDATE of an EXISTING binary DTE TRACE SYSTEM ????↲
╞ type yes or no ┆b0┆: no↲
╞ dte trace compilation↲
╞ dte trace process generated↲
╞ dte outtrace compilation↲
╞ dte outtrace process generated↲
╞ ***lookup tempdte unknown↲
╞ dte trace system generation ended↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆G.╞ BUFFER LAYOUT IN CALL SET-UP PHASE.↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 49: ┆84┆Layout and transfer of call-parameters from User ↓
┆19┆┆94┆┄┄dte_call_req to X.25 CALL REQUEST packet.↲
↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
↲
╞ Figure 50: ┆84┆Layout and transfer of call parameters from an INCOMING ↓
┆19┆┆94┆┄┄CALL Packet to an Internal Buffer and a User Buffer.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆H.╞ INDEX↲
↲
┆a1┆┆b0┆H.1╞ Survey of Figures.↲
↲
╞ Figure 1: Process tree of the External DTE and its environment.↲
╞ Figure 2: ┆84┆Process tree of the DTE debugging, test and trace ↓
┆19┆┆94┆┄┄tools.↲
╞ Figure 3: Message flow of normale data.↲
╞ Figure 4: Message flow of interrupt data.↲
╞ Figure 5: Message flow of X.25 control packet output.↲
╞ Figure 6: Message flow at Virtual Call Set-up.↲
╞ Figure 7: External Interfaces of the DTE module.↲
╞ Figure 8: Message flow between the DTE module and the NCP.↲
╞ Figure 9: Snap shot of routing pointers.↲
╞ Figure 10: Buffer flow for bigbuf, smallbuf, x25buf.↲
╞ Figure 11: Relation between streams and logical channels.↲
╞ Figure 12: State transition graph for dte_state in process dte.↲
╞ Figure 13: Flow of messages to and from dte.↲
╞ Figure 14: process dte, main flowchart.↲
╞ Figure 15: process dte, part (B) flowchart.↲
╞ Figure 16: process dte, part (C) flowchart.↲
╞ Figure 17: Process dte, part (D) flowchart.↲
╞ Figure 18: Process dte, part (E) flowchart.↲
╞ Figure 19: Process dte, part (F) flowchart.↲
╞ Figure 20: Process dte, part (G) flowchart.↲
╞ Figure 21: process dte, part (H) flowchart.↲
╞ Figure 22: Process dte, part (I) flowchart.↲
╞ Figure 23: Process dte, part (J) flowchart.↲
╞ Figure 24: Snap shot of tables connections.↲
╞ Figure 25: Flowchart for HDLC event treatment.↲
╞ Figure 26: ┆84┆State transition graph for dte_state in process ↓
┆19┆┆94┆┄┄dte_access.↲
╞ Figure 27: Flow of message to and from dte_access.↲
╞ Figure 28: Process dte_access, main flowchart.↲
╞ Figure 29: Flow of messages to and from dte_hrec.↲
╞ Figure 30: Process dte_hrec, main flowchart.↲
╞ Figure 31: ┆84┆State transition graph for p_level_state in process ↓
┆19┆┆94┆┄┄dte_lcnzero.↲
════════════════════════════════════════════════════════════════════════
↓
╞ Figure 32: Flow of messages to and from dte_lcnzero.↲
╞ Figure 33: Process dte_lcnzero, main flowchart.↲
╞ Figure 34: Flow of messages to and from dte_chan.↲
╞ Figure 35: Process dte_chan, main flowchart.↲
╞ Figure 36: Process dte_chan, part (C) flowchart.↲
╞ Figure 37: Process dte_chan, part (D) flowchart.↲
╞ Figure 38: process dte_chan, part (E) flowchart.↲
╞ Figure 39: Process dte_chan, part (F) flowchart.↲
╞ Figure 40: Process dte_chan, part (G) flowchart.↲
╞ Figure 41: Acknowledgement strategy flowchart.↲
╞ Figure 42: Message flow in the trace system.↲
╞ Figure 43: Message flow of testmessages.↲
╞ Figure 44: DTE System text and job connections.↲
╞ Figure 45: ┆84┆Process dte_chan, state transition graph for the call ↓
┆19┆┆94┆┄┄set-up and clear phases.↲
╞ Figure 46: ┆84┆Process dte_chan, state transition graph for the data ↓
┆19┆┆94┆┄┄phase.↲
╞ Figure 47: ┆84┆Process dte_chan, state transition graph for the reset ↓
┆19┆┆94┆┄┄phase, part 1.↲
╞ Figure 48: ┆84┆Process dte_chan, state transition graph for the reset ↓
┆19┆┆94┆┄┄phase, part 2.↲
╞ Figure 49: ┆84┆Layout and transfer of call parameters from User Call ↓
┆19┆┆94┆┄┄Request to X.25 Call request.↲
╞ Figure 50: ┆84┆Layout and transfer of call parameters fron an Incoming ↓
┆19┆┆94┆┄┄Call Packet to an Internal Buffer and a User Buffer.↲
↲
↲
┆a1┆┆b0┆H.2╞ Survey of Tables.↲
↲
╞ Table 1: Processing of DTE User operations.↲
╞ Table 2: HDLC operations utilized by the DTE module.↲
╞ Table 3: ┆84┆Environments in which address types and constants are ↓
┆19┆┆93┆┄┄defined.↲
╞ Table 4: ┆84┆Process dte, internal state/action table for dte_chan ↓
┆19┆┆93┆┄┄incarnations.↲
╞ Table 5: ┆84┆Process dte, internal state/action table for logical ↓
┆19┆┆93┆┄┄channels.↲
════════════════════════════════════════════════════════════════════════
↓
╞ Table 6: Process dte, state transition table for line_state.↲
╞ Table 7: ┆84┆Process dte_access, state transition table for ↓
┆19┆┆93┆┄┄user_state.↲
╞ Table 8: State variables of the Trace System.↲
╞ Table 9: Process dte, testrecord kind and parameter fields.↲
╞ Table 10: ┆84┆Process dte_lcnzero, testrecord kind and parameter ↓
┆19┆┆93┆┄┄fields.↲
╞ Table 11: Process dte_chan, testrecord kind and parameter fields.↲
╞ Table 12: Storage requirements of the DTE System.↲
╞ Table 13: Process dte_access, user dependent state/action table.↲
╞ Table 14: Process dte_access, stream dependent state/action table.↲
╞ Table 15: ┆84┆Process dte_access, stream independent state/action ↓
┆19┆┆93┆┄┄table.↲
╞ Table 16: Process dte_lcnzero, state/action table.↲
╞ Table 17: Process dte_chan, state/action table.↲
╞ Table 18: ┆84┆Print format for testoutput from the processes ↓
┆19┆┆93┆┄┄dte_lcnzero and dte_chan.↲
↲
↲
┆a1┆┆b0┆H.3╞ Survey of Examples.↲
↲
╞ Example 1: Example of DTE address.↲
╞ Example 2: ┆84┆Example of user_id_length greater than sub address ↓
┆19┆┆94┆┄┄length.↲
╞ Example 3: ┆84┆Example of user_id_length smaller than sub address ↓
┆19┆┆94┆┄┄length.↲
╞ Example 4: Operator commands for update of an existing binary dte.↲
╞ Example 5: ┆84┆Operator commands for generating the X.25 procedure ↓
┆19┆┆94┆┄┄library.↲
╞ Example 6: ┆84┆Operator commands for update of the X.25 procedure ↓
┆19┆┆94┆┄┄library.↲
╞ Example 7: Operator commands for generating the Trace System.↲
════════════════════════════════════════════════════════════════════════
↓
↲
↲
┆1a┆┆1a┆.4. All operator operations are i