PLEX-C2



Ericsson Telecom AB 1999, Stockholm, Sweden

All rights reserved. No part of this document may be reproduced in any
form without the written permission of the copyright holder.

PREFACE

Use this book as a course book in Ericsson’s internal training programs.
The book is a training document and contains some simplifications. Do not
consider the information in this book as a specification of the system.

The contents of this book are subject to change without notice due to con-
tinued development in design and manufacture.

The course is particularly helpful for staff working as AXE Block Design-
ers.

To be able to fully benefit from the contents of this course, the trainees
should participate in the “AXE 10 Training Path for Block Designers”. The
training path covers AXE design methodology, CP SW unit design and
basic test, support systems and AXE concepts and characteristics..

Ericsson Telecom AB

Internal Training Marievik, MV/ETX/X/HCD



Ericsson Telecom AB 1999, Stockholm, Sweden

All rights reserved. No part of this document may be reproduced in any
form without the written permission of the copyright holder.

Table of Contents

Chapter 1

Design Essentials

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Source System, Product Line and Application System . . . . . . 1

Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Fault Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Modular Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Correction Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Fault Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Common Design Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Handbooks and Design Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Software Reliability Handbook. . . . . . . . . . . . . . . . . . . . . . . . . 8

System Characteristics Handbook . . . . . . . . . . . . . . . . . . . . 10

DRtool: Design Rules and Design Descriptions . . . . . . . . . . 11

STEG-DC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

DRtool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

TOMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Reviews and Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 2

APZ Basics

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

APZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Fault Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Database Management Subsystem . . . . . . . . . . . . . . . . . . . 21

Evolution of the APZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Chapter 3

Loading, Dumping and Variable Properties

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Initial Loading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Plex-C 2

Dumping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Large Data Dump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Small Data Dump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Dump Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Reloading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Manual Reloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Automatic Reloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Command Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Program Characteristics for Command Logging . . . . . . . . . . 33

Variable Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Function Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

STATIC variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Changing the Data Structure. . . . . . . . . . . . . . . . . . . . . . . . . 37

Furax and Fuspel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

DCI Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Function Change Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Function Change Method 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Function Change Method 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Comparison: Method 1 versus Method 2. . . . . . . . . . . . . . . . 48

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Chapter 4

CP-CP Unit Interaction

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Signal Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Finding Block References . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Signal Acceptance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Block Type and Block Type Extension . . . . . . . . . . . . . . . . . . . . . . 55

Block Type Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Code in Parameter List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Masking Block Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Function Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Linking of Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Optional Blocks in AXE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Chapter 5

Commands

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Input-Output Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Time Gaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Interference Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Job Buffer Level C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Command Category Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Contents of COCA numbers . . . . . . . . . . . . . . . . . . . . . . . . . 75

COCA Number in Command Receiving SW unit . . . . . . . . . 76

Command Parameters and IOCODE. . . . . . . . . . . . . . . . . . . . . . . 77

FETCH PARAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Syntax Error, Bit 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Declaring the IOCODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Error Printouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Order of IOCODE Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Translation Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Command Reception for Multiple Users . . . . . . . . . . . . . . . . . . . . 84

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Chapter 6

Printouts

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Printout Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Translation Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

WRITE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

EOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

IOCODE in WRITE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Printout Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Check Printouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Procedure Printouts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Answer Printouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Printout Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Standard Text Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Chapter 7

Software Recovery

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Start/Restart after Initial Loading . . . . . . . . . . . . . . . . . . . . . . . . . 100

System Recovery Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Plex-C 2

Intensity Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Forlopp Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Selective Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

System Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

The Start/Restart Routine in a Function Block. . . . . . . . . . . . . . . 112

General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Absolute Start Phases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Symbolic Start Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Variables STATE, BLSTATE and ADMSTATE. . . . . . . . . . . . . . . . 118

Start of RP/EMRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Handling of Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

STTOR/STTORRY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Signalling Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

The Start/Restart Routine in a PLEX Program . . . . . . . . . . . . . . 125

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Chapter 8

Job Execution

139

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Program Administration in APZ . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Job Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Job Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Time Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Jobs and Execution Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Time Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Buffer Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Phase Division: Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . 148

C-Level Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Selection of Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Level Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Variable Interference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Avoiding Variable Interference . . . . . . . . . . . . . . . . . . . . . . . 157

Preventing Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Chapter 9

Size Alteration

163

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Need for Size Alteration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Global and Local Size Alteration Events . . . . . . . . . . . . . . . . . . . 165

Operating of Size Alteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Block SAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

CPREPNUM and CINDNUM . . . . . . . . . . . . . . . . . . . . . . . . 168

Size Alteration Troubles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Size Alteration Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Scenario 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Scenario 4a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Scenario 4b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Scenario 4c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

SAE Signalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

SAE Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

SAE Flowcharts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

SAE for HW and SW Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Connecting and Deblocking a Device . . . . . . . . . . . . . . . . . 187

Signal Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Chapter 10

Job Table Signals

199

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Plex-C Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Chapter 11

Time Supervision and Time Measurement

203

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Introduction to the Clock-Timer Method . . . . . . . . . . . . . . . . . . . . 204

Efficient Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Stepping CLOCK by 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Example on Clock-Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Timeout Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Plex-C 2

Supervision Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Clock-Timer Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Restarts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Please . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Indexed Linked Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Comparison: Clock-Timer versus Linked Lists. . . . . . . . . . . . . . . 214

Stop-Clock Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Chapter 12

Efficient Design

217

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Efficient Data Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Improved Use of Memory . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Efficient Program Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Focus on the Normal Case . . . . . . . . . . . . . . . . . . . . . . . . . 220

Iterations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Chapter 13

CP-RP/EMRP Interaction

223

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Regional Processor Subsystem. . . . . . . . . . . . . . . . . . . . . . . . . . 223

Regional Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Software Functions of RP . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Types of Regional Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Extension and Control Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 227

RP2 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

RP2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

EMRP Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

CP-RP Unit Interaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Code Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

CP-EMRP Unit Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Code Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Chapter 14

Exercises

239

Exercise 1: Design Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Exercise 2: Block Type and Type Extension. . . . . . . . . . . . . . . . . 242

Chapter 15

Mini Project

243

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Structure of block SELECT . . . . . . . . . . . . . . . . . . . . . . . . . 244

Structure of block DEVICE . . . . . . . . . . . . . . . . . . . . . . . . . 244

Function Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Exercise Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Input Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Exercise Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Exercise Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Task 1 Declaring variables. . . . . . . . . . . . . . . . Chapter 3 249

Task 2 Block Types and Type Extensions . . . . Chapter 4 249

Task 3 Command Reception and Analysis . . . Chapter 5 249

Task 4 Printout DEVICE STATE SURVEY . . . . Chapter 6 249

Task 5 Finding an idle device record . . . . . . . . Chapter 6 249

Task 6 Start/Restart subprograms . . . . . . . . . . Chapter 7 249

Task 7 Level Change . . . . . . . . . . . . . . . . . . . . Chapter 8 251

Task 8 Size Alteration Events . . . . . . . . . . . . . Chapter 9 251

Task 9 Phase Division and Time Superv. . Chapters 8,11 252

Block Description - SELECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Block Description - DEVICE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Command Description - EXDSC . . . . . . . . . . . . . . . . . . . . . . . . . 264

Printout Description - Device State Survey . . . . . . . . . . . . . . . . . 267

Signal Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Chapter 16

Command STDEP

273

Command Description - STDEP . . . . . . . . . . . . . . . . . . . . . . . . . 274

Printout Description - Device State Details . . . . . . . . . . . . . . . . . 277

Chapter 17

Index

281

Plex-C 2

Chapter 1

Design Essentials

Introduction

This chapter describes some essential AXE concepts and explores the
costs of maintaining the AXE system. The chapter introduces useful hand-
books as well as rules to be followed when designing AXE software.

Figure 1.1

Chapter Objectives.

Concepts

The first section of this chapter lists some essential concepts every AXE
designer should be familiar with.

Source System, Product Line and Application System

A source system is a group of products which fit and work together. The
products can communicate with each other. The source system is a plat-
form for development activities, and it is easy to add new products to this
platform.

AXE products include subsystems, blocks, and units. Note that source sys-
tems, and also subsystems and blocks, consist of hardware and software
components.

New products and corrections are designed within the source system. APZ
and APT source systems are developed independently of each other. The
APZ source system mainly depends on the APZ processor type. For APT,
a large number of source systems exist. Different applications, for instance
European and Pacific mobile telephony, may be based on the same APT
source system.

Chapter Objectives

After completing this chapter, you are able to

• Describe essential AXE concepts

• Understand the costs of correcting AXE software

• Describe the support available to AXE designers to prevent faults

• Find and use design rules and design descriptions using DRtool

Plex-C 2

Figure 1.2

Examples of source systems and some of their subsystems

Figure 1.2 shows examples of an APT and an APZ source
system. This and the following pictures are simplified and do
not necessarily describe existing products or systems. See
Chapter 2, APZ Basics for a discussion of APZ subsystems,

and reference [5], AXE 10 Survey, for a presentation of APT subsystems.

Since products in an APT source system can be used in different applica-
tions, the concept of the product line was introduced. A product line is a
set of hardware and software products from one APT source system that is
designed for one type of exchange, e.g. a local exchange, a transit
exchange or a mobile switching centre.

Figure 1.3

Product lines are based on source systems

In Figure 1.3, product line MG/APT 210 15/4 is based on source system
APT 210 15/4. The product line contains modifications and additions to
the source system. Adaptations may include the mobile base stations, radio
traffic and No. 7 signalling.

APZ 212 20

for CPU APZ 212 20

GSS

TCS

TSS

. . .

CPS

RPS

FMS

. . .

APT 210 15/4

Mobile Telephony Platform

APZ 212 20

for CPU APZ 212 20

GSS

TCS

TSS

. . .

CPS

RPS

FMS

. . .

APT 210 15/4

Mobile Telephony Platform

GSS

TCS

TSS

. . .

MG/APT 210 15/4

GSM system CME 201 R5

Source System

Product Line

Design Essentials

An application system is designed for a specific market or customer. The
application system is thus market-dependent. It consists of a subset of
products from one APT product line and one APZ source system. Current
APT product lines can be combined with most newer APZ source system,
but not all combinations are possible.

Figure 1.4

Application systems are based on product lines based on source systems

Figure 1.4 shows two of the many application systems based on product
line MG/APT 210 15/4. The application system AXE 105 09/17 contains
all standard functions and default parameters. The other application sys-
tem, AXE 105 09/52, is adapted to the specific needs of the UK network
operator Cellnet. The adaptations include market-specific functions as well
as adaptations in handling No. 7 signals in subsystem TCS.

Market-dependent parameters, such as tone types used for signalling and
printouts in different languages, are not included in the program units or
the source system. It is the parameter list which contains values for these
market-dependent parameters. This document, that is, the parameter val-
ues, differ from operator to operator. Add these parameter lists to complete
the application system.

APZ 212 20

for CPU APZ 212 20

GSS

TCS

TSS

. . .

CPS

RPS

FMS

. . .

APT 210 15/4

Mobile Telephony Platform

GSS

TCS

TSS

. . .

MG/APT 210 15/4

GSM system CME 201 R5

GSS

TCS

FMS

. . .

AXE 105 09/17

GSM system CME 201 R5

Standard application system

GSS

TCS

FMS

. . .

AXE 105 09/52

GSM system CME 201 R5

AS for UK operator Cellnet

Source System

Product Line

Application System

Plex-C 2

An application system forms the basis of many exchanges, with local
adaptations. All exchanges in an application system share the same pro-
gram code. Individual exchanges may differ in hardware configuration and
exchange-dependent parameters, such as subscriber data and routing infor-
mation. These data have to be added by means of commands.

Figure 1.5 shows how to develop exchanges from source systems via prod-
uct lines and application systems.

Figure 1.5

An exchange made using an APT product line and an APZ source system

This course discusses exchange-dependent parameters in Chapter 3, Load-
ing, Dumping and Variable Properties and market-dependent parameters
in several chapters, for instance, Chapter 4, CP-CP Unit Interaction.

Costs

Better in-service performance is one of Ericsson’s major goals. Ericsson
has built up a reputation of offering reliable hardware, while our software
products do not meet the same standards. Software faults cause much more
exchange downtime than hardware problems.

Exchange

Application System

APT + APZ

Source System

APT

Product

Line

Source System

APZ

Market-dependent parameters

Exchange-dependent parameters

Design Essentials

Poor in-service performance is one of the most common complaints from
our customers. This is partly because a fault has such large consequences,
often a system restart or a hanging call, which will not only be annoying to
the telecom operator, but also visible to the end user.

Design faults in the AXE system lead to large, direct and indirect costs.
Function and system testers as well as customer support staff will write a
Trouble Report (TR) for every fault. A large database, the Modification
Handling System (MHS), handles TRs and software corrections.

Ericsson employs hundreds of experts for debugging, testing, correcting,
and updating the AXE software. In 1991, each TR cost Ericsson approxi-
mately [source: Software Reliability Handbook]:

•

10 kSEK (US$ 2,000) if the fault was found in function test

•

10 kSEK (US$ 2,000) if the fault was found in source system or prod-
uct line test

•

35 kSEK (US$ 7,000) if the fault was found in service.

This list shows only the direct costs; the indirect costs include the effect on
customer satisfaction and, consequently, market share. It is much harder to
calculate or predict these indirect costs.

Fault Handling

The following concepts help to prevent faults and make it simpler to cor-
rect faults.

Figure 1.6

Concepts in Fault Handling

Modular Design

All AXE exchanges consist of several subsystems, which in turn consist of
several blocks, which in turn consist of one or three units. The modular
structure makes it possible to track down and correct faults without great
difficulty, and only small parts of the entire system need to be corrected/
updated.

Modular Design

Correction Handling

• Emergency Correction

• Approved Correction

• Correction Note Issue

Plex-C 2

Correction Handling

There are three ways to correct software faults in an AXE exchange.

•

Emergency Correction (EC): A support technician writes the correc-
tion, an assembler patch, on his/her own. The technician loads the
assembler patch into the exchange by command. ECs are only neces-
sary in urgent, exceptional cases.

•

Approved Correction (AC): A software designer writes an assembler
patch. The test department tests the correction to make sure the origi-
nal fault is fixed and that the correction does not spawn other prob-
lems. Customer support technicians load the assembler patch into the
exchange by command. ACs are recommended when the AXE soft-
ware has problems with traffic handling, and further delay of the cor-
rection is not acceptable.

•

Correction Note Issue (CN-I): A designer rewrites the SW unit in
Plex-C and tests it thoroughly before its implementation. Support
technicians load the complete program code of one or more SW units
into the exchange. This procedure is called function change; see Func-
tion Change on page 36. Use CN-Is in less urgent cases, or if
Approved Corrections are not applicable for technical reasons.

Note that support technicians load ECs and ACs into the correction area
assigned to each SW unit in the program store. However, the space of the
correction area is limited and after several corrections for one SW unit, the
correction area may be too small. In this case, the entire SW unit has to be
replaced using a CN-I. Distributing and installing CN-Is is expensive for
Ericsson, and these costs cannot be invoiced to the customer.

Fault Prevention

Rather than handling faults, it is much better and less expensive to avoid
faults from the beginning. Each software designer should strive to deliver
error-free software products. Some AXE designers lack the necessary
competence or experience, and this is the cause of most software faults.
Designers can avoid software faults by using the material and concepts
shown in Figure 1.7.

Design Essentials

Figure 1.7

Support in Fault Prevention

•

Designers ought to read and follow the Software Reliability Handbook
and the AXE System Characteristics Handbook.

•

Designers ought to read and follow design rules and design descrip-
tions.

•

Designers ought to read and follow process descriptions and other
method documents included in TOMAX.

•

Designers ought to use document inspections, code reviews, desk
check, basic and function test to locate flaws as early as possible.

Each of these points is discussed in some more detail below.

Common Design Errors

Designers should be aware of the most common faults to avoid repeating
the mistakes others have made before. The Software Reliability Handbook
describes the analysis of 400 trouble reports in the design project FM P2.
See chapter 2.5.1 in the handbook, reference [2].

Figure 1.8

Common design faults

• Handbooks

• Design Rules and Design Descriptions

• Process Descriptions/TOMAX

• Reviews and Tests

Logical Faults
49 %

Others
19 %

Signal Faults
32 %

Plex-C 2

According to the study, logical faults (49%) and signal faults (32%) were
most common. The logical faults include the following error types:

•

variable faults (19% of the total);
Variable assigned a faulty value or no value. Faulty declaration of var-
iable. Variable missing. Wrong variable used.

•

incorrect IF/CASE statements (18% of the total);
Checks are not made or are faulty.

•

pointer faults (4% of the total);
Pointer assigned a faulty value, no value or not reset. Wrong pointer
used.

•

counter faults (3% of the total);
Counter incremented or decremented faulty or not at all.

The signal faults include the following error types:

•

signal data faults (16% of the total);
Signal data is faulty or missing.

•

missing signals (8% of the total);
Signal is not sent or signal is not received.

•

incorrect handling of signals (7% of the total);
Signal is received in wrong state or wrong signal is sent.

For further information, please study chapter 2 of the Software Reliability
Handbook, reference [2].

Handbooks and Design Rules

AXE exchanges are complex systems. Large, international projects design
real-time software for AXE switches. Therefore, it is essential that the
software designers follow the detailed rules and guidelines collected in
various handbooks and on-line libraries.

Software Reliability Handbook

The handbook offers a collection of Plex-C solutions to common imple-
mentation problems, accompanied by problems and hints. The handbook
concentrates on error-prone areas of the code such as:

•

data structure

•

restarts

•

size alteration

•

time supervision

•

idle list

For most types of subprograms, the book lists common faults, gives back-
ground information and design rules, and includes good examples of
Plex-C code. See reference [2].

Design Essentials

Figure 1.9

Cover of the Software Reliability Handbook

Plex-C 2

System Characteristics Handbook

The handbook motivates and supports designers, testers, sales staff and
trainers in their work. The book does not contain detailed requirement
specifications or design rules. Instead, the book addresses important AXE
system characteristics such as:

•

call capacity

•

utilization of hardware and software resources (e.g. memory and sys-
tem buffers)

•

data throughput of buses

•

reliability

The book includes useful hints on writing efficient code that makes the
most of the system’s resources. See reference [1].

Design Essentials

Figure 1.10

Cover of the AXE System Characteristics Handbook

DRtool: Design Rules and Design Descriptions

For most parts and problems of AXE software design, special design rules
and descriptions exist. These documents:

•

specify how certain characteristics/properties of the AXE system
should be implemented

•

describe system concepts and internal standards in AXE

•

coordinate design work and describe standardised implementation
methods

•

describe methods for increasing the efficiency of the code

See the document instruction, reference [4], for more details.

Plex-C 2

Design Rules and Design Descriptions. AXE designers have to follow
applicable design rules (DRs), while design descriptions (DDs) are non-
binding documents. Designers should follow DDs, but it is not necessary
to ask for an exemption if the design project decides not to follow a DD.

STEG-DC

STEG, the System Technology Expert Group, has the overall responsibil-
ity for the further development of AXE. STEG-DC, the STEG Drafting
Committee, is a body in STEG and responsible for checking and approv-
ing new design rules and descriptions. STEG-DC can also grant exemption
to a design project, if the project cannot follow a design rule.

DRtool

The DRtool in APStools provides access to more than 400 design rules at
this point (August 1996).

Figure 1.11

The tree structure in DRtool

Design Essentials

DRtool accesses an Sybase database of DRs and DDs. DRtool’s graphical
interface allows to navigate through a tree of DRs and DDs. DRtool sup-
ports searching for DRs and DDs matching certain search criteria, reading,
fetching, and printing design rules and descriptions.

All DRtool installations use a central Sybase database in Stockholm main-
tained by a librarian who has the authority to create, change, update and
delete design rules in the database.

Before designing a block, the software designer should access all relevant
DRs and DDs. Understanding and properly using these documents helps to
ensure that the design documents follow Ericsson standards. All projects
must follow the DRs and DDs.

TOMAX

AXE design work is split in several processes, eg. function design, block
design, and unit design & basic test. For each process, a detailed step-by-
step guide called process description lists activities in their suitable order.
Activities which require special attention, are explained in further detail in
work instructions. For each type of document, a document instruction
defines contents, structure and headings.

The WWW-based TOMAX tool provides easy access to these process
descriptions, work instructions and document instructions. TOMAX can
be started from APStools.

Reviews and Tests

In AXE design, different types of reviews and tests are used. The sooner
an error is detected, the easier and less expensive it is to correct.

•

Inspections
Meeting where several software designers discuss and check AXE
design documents (not normally carried out for program code docu-
ments).

•

Code Review
Informal meeting where project colleagues discuss and check your
program code. Optional.

•

Desk Check
Experienced designer reviews the complete program of a software
unit. The source documents have to follow applicable design rules and
descriptions. Checklists and the autodctool help the desk checker in
this task. Desk check is the first part of basic test.

•

Emulator Test
The programmer of the SW unit tests the program in the APZ emula-
tor, a UNIX tool emulating the behaviour of an AXE exchange. Emu-
lator test is the second part of basic test.

•

Function Test
Testing engineers verify complete functions by giving commands or
making fake phone calls in an AXE test plant. In many cases, the APZ

Plex-C 2

emulator can replace the (expensive) AXE test plant during function
test.

Chapter Summary

From this chapter you should remember these points:

Figure 1.12

Summary of Chapter 1

• Market- and exchange specific parameters adapt an AXE

exchange to the local needs of the telecom operator.

• Software faults are very costly.

• There are means to avoid faults, for instance by making a proper

desk check.

• Look up all relevant design rules and descriptions before pro-

gramming.

• Check the information in Tomax, the SW Reliability Handbook

and the System Characteristics Handbook before programming.

Design Essentials

References

Important note: the following book is intended for internal use only. Dis-
tribution outside majority owned Ericsson companies is prohibited.

[1]

AXE System Characteristics, Handbook, Volume 1 and 2,
EN/LZB 101 1978-1, EN/LZB 101 1978-2
© Ericsson Telecom 1995
<handbook available via formatted memo INFAR in the open mailbox
OPNPIC from ETX in Karlstad>

See also http://symax.ericsson.se/systemware/char_handb/contents.html
on WWW.

Important note: the following book is intended for internal use only. Dis-
tribution outside majority owned Ericsson companies is prohibited.

[2]

Software Reliability Handbook, Edition 4,
EN/LZG 205 603
© Ericsson Telecom 1996
<handbook available via formatted memo INFAR in the open mailbox
OPNPIC from ETX in Karlstad>

See also http://symax.ericsson.se/systemware/srh_ed4/srhtoc.html on
WWW.

[3]

DRtool User Guide
2/198 17-CAA 139 1124 Uen
© Ericsson Infocom 1994
<document available via APStools/Docs>

[4]

Document Instruction for Design Rule/Design Description
UAB/B/U-96:507 Uen
© Ericsson Utveckling AB 1996
<document available via APStools/DRtool>

[5]

AXE 10 Survey
LZT 101 1513
© Ericsson Telecom AB 1996
<document available via formatted memo BOOK-ORDER in the open
mailbox OPNTRAIN from ETX in Marievik, Stockholm>

Plex-C 2

Chapter 2

APZ Basics

Introduction

This module describes concepts of the APZ control system that are rele-
vant to Plex-C designers. A second section summarises the different ways
of delaying signals.

Figure 2.1

Chapter Objectives.

APZ

The APZ is the control and support system of an AXE 10 exchange. The
APZ has two major tasks:

Data Processing. The central and regional processors execute the APZ
and APT programs. The maintenance subsystem supervises the programs,
and if a fault occurs, necessary actions are initiated.

Input-Output Handling. Support processors run I/O communication
programs. Dedicated subsystems allow I/O communication with operators,
files, and data traffic. The four I/O subsystems together are known as
input-output group or IOG-11.

The APZ consists of eight subsystems, see Figure 2.2. For more informa-
tion, see also reference [1].

Chapter Objectives

After completing this chapter, you are able to:

• Describe the background of AXE 10 processors

• Describe the interaction between the CPS and other APZ subsys-

tems

Plex-C 2

Figure 2.2

APZ hierarchy and subsystems

These are the APZ subsystems:

CPS.

Central Processor Subsystem

RPS.

Regional Processor Subsystem

MAS.

Maintenance Subsystem

DBS.

Database Management Subsystem (see page 21)

SPS.

Support Processor Subsystem

MCS.

Man-machine Communication Subsystem

DCS.

Data Communication Subsystem

FMS.

File Management Subsystem

The Central Processor Subsystem (CPS) is most relevant to the CP soft-
ware designer and will be discussed in this chapter. For a detailed descrip-
tion of the other APZ subsystems, refer to the course book AXE 10 Survey
[1] please.

The CPS is the intelligent part of the APZ and includes the central proces-
sors. The CPS takes care of the following tasks:

•

Executes programs and handles data in the central processors

•

Controls different program priorities and allocates the central proces-
sor

•

Contains memory for programs and data and supervises the memory
usage

•

Allows to change, modify and delete AXE software units

APZ

AXE

APT

System Level 1

System Level 2

Subsystems

CPS

RPS

SPS

MCS

DCS

FMS

Data Processing

Input-Output Group

DBS

MAS

APZ Basics

•

Administers initial loading of programs and data, dumps main mem-
ory (CP stores) contents for backup purposes, and allows to reload
data after serious faults

•

Allows to increase and decrease the number of records in a file (size
alteration event)

•

Contains functions for directly inserting program corrections (assem-
bler patches) for serious, urgent errors

•

Supervises processor load and takes actions to reduce CP load if
needed

•

Allows to trace software signals or program variables

Figure 2.3 shows the interaction between CPS and other APZ subsystems.

Figure 2.3

Interaction with the CPS

DCS

FMS

MCS

APZ

SPS

CPS

MAS

RPS

Data Channel

Floppy Disk

Alarm Panel

Printer

Personal

Computer

Hard Disk

Optical Disk

RP Bus A

RP Bus B

RPA

APT Hardware

CP-A

Store

MAU

APT SW

APZ SW

CP-B

Plex-C 2

Fault Detection

To increase the reliability of the AXE exchanges, the central processors
are duplicated with an A-side and a B-side in all types of APZ.

During normal operation, the A-side is in EXecutive (EX) state and the B-
side is in StandBy/Working (SB/WO) state.

The CP side in EX state controls the Regional Processors (RP), which are
connected to both CP sides. The CP side in SB/WO state performs exactly
the same functions as the EX side, except that the signals it sends to the
RPs are not read into the RPs - the signals are used to check that both CPs
are sending the same data.

The work of the two processors (EX and SB) is continuously compared
(data is sent on a bus from the EXecutive side to the StandBy side) so that
any fault is detected immediately.

In the case of a data mismatch, the states of the two CP sides change - for
example, in the event of an error in the A-side, the B-side becomes EXec-
utive and the A-side is halted. There is no interruption of traffic handling
during such a procedure. This change is administered by the Maintenance
Unit (MAU) in the APZ 212 family.

Table 2.1 shows the possible states of the CP sides.

CP-A

CP-B

Executive

SB/WO Standby/Working
Normal state.

Executive

SB/HA Standby/Halted
Due to a permanent error or frequent
faults, the CP side stopped executing
programs.

Executive

SB/SE Standby/Separated
Both CP sides are separated by com-
mand. Used when loading new software
in one of the CPs.

Executive

SB/UP Standby/Updating
The CP side in EX state updates the
software in the CP side in SB state, so
that both CPs will work in parallel.

If necessary, the central processors A and B can switch roles, so that
CP-B is in EX state and CP-A in SB state.

Table 2.1

States of the Central Processors

APZ Basics

Database Management Subsystem

This is the latest subsystem in APZ and consists of SW only. Note that
Figure 2.3 does not show the DBS, because this subsystem does not con-
tain any hardware.

DBS is a semi-relational database management system with extensions to
support real-time requirements and with adoptions for easy integration in
AXE.

DBS administers permanent and semipermanent data in tables or relations.
These data replace the exchange data or RELOAD-marked variables in CP
SW units. These units no longer need their own MML commands or com-
mand-handling routines. Instead, DBS provides a set of 8 standard com-
mands which affect the data in the tables.

Plex-SQL is a new Plex-C dialect including standard query language
(SQL) statements to manage and access the tables in the DBS database.
Plex-SQL is precompiled into Plex and ASA. For more details on DBS,
see references [7] and [8].

Evolution of the APZ

The development of the APZ is directly connected to the development of
the central processors. Each new APZ also included a new generation of
CPs. Major differences included the total number of blocks, larger mem-
ory and higher processor capacity.

The APZ 211 processor family was developed as a low-cost standard proc-
essor. The APZ 212 processor series provides high-capacity memory and
computing facilities. The new APZ 212 25, however, is a compact and
low-cost processor. Some typical processor data is shown in Table 2.2.

Plex-C 2

In this table holds: 1k = 2

= 1024. 1 M = 2

= 1,048,576. The word

length (W) is 16 bits unless otherwise noted, i.e. W(32) or W(40). See also
references [2], [3], [4], [5] and [6]. APZ 212 30 moved the back-up from
PS to DS. Hence, the ‘real’ PS increased by factor 2 or absolute 32 MW.

Figure 2.4 shows how the new compact APZ 212 25 reduces the footprint
or magazine space for the CP processors. For more details see reference
[6].

Parameter

APZ

211 10

APZ

212 11

APZ

212 20

APZ

212 25

APZ

212 30

Data Store

192 MW

380 MW

252 MW

1500 MW

Program Store

12 MW

32 MW

64 MW

Reference Store

1 MW(40)

2 MW(32)

8 MW(16)

Records per File

1 M

CP SW unit size

64 kW

No. of Base
Addresses

4095

No. of SW units

1023

2047

Correction Area

1024 W

Number of RPs

512

1024

Number of EMGs

256

Clock Frequency

10 MHz

40 MHz

20 MHz

50-80

MHz

Relative Call-han-
dling Capacity

CP SW unit size: length of the program’s object code
Correction Area: size per software unit.
No. of Base Addresses: number per software unit.
The APZ 212 20 provides 4 times as much call-handling capacity as the APZ
212 11 which in turn is 4 times as powerful as the APZ 211 11.

Table 2.2

APZ System Limits

APZ Basics

Figure 2.4

Possible reduction of size with Mini-CP APZ 212 25

Chapter Summary

Remember these points from this chapter.

Figure 2.5

Summary

References

[1]

AXE 10 Survey,
EN/LZT 101 1513 R2A,
© Ericsson Telecom AB 1995

[2]

System Limits (Function Specification for APZ 212 20)
1/155 17-ANZ 211 60 Rev. A,
Ericsson Telecom AB 1994

[3]

System Limits (Function Specification for APZ 212 11)
4/155 17-ANZ 211 41 Rev. A,
Ericsson Telecom AB 1995

1 5

1 5 1015202530

1 5 10

1 5 101 5 10

1 5 10

BM 6

CP-B

1 5 1015202530

1 5 10

1 5 101 5 10

1 5 10

BM 6

CP-A

APZ 212 20 in BYB 202 cabinets

CP-A & CP-B

Mini CP in BYB 501 cabinet

• APZ consists of seven subsystems: CPS, RPS, MAS, SPS,

MCS, DCS, and FMS

• Brave new world: the central processors are constantly getting

faster, more powerful, more efficient but also smaller

Plex-C 2

[4]

System Limits (Function Specification for APZ 211 11)
9/155 17-ANZ 211 51 Uen Rev. C,
Ericsson Telecom AB 1994

[5]

System Limits (Function Specification for APZ 211 10)
9/155 17-ANZ 211 50 Uen Rev. A,
Ericsson Telecom AB 1992

[6]

APZ 212 System Limits
http://uabweb.uab.ericsson.se/~tx/projects/Mini-CP/limits.html
Ericsson Utvecklings AB 1996

[7]

Data in DBS (Design Rule)
ETX 102 60-1136 Uen
Ericsson Telecom AB 1995

[8]

An Introduction to DBS
TX/Z-91:0297 Uen
Ericsson Telecom AB 1995

Chapter 3

Loading, Dumping and
Variable Properties

Introduction

This chapter focuses on the declare sector in a Plex-C program. Students
learn about different types of loading and dumping data in order to declare
all program variables properly.

Figure 3.1

Chapter objectives.

General

When the system software is designed, tested and compiled to machine
code, the programs, the initial data set in the data sector and the initial val-
ues for the exchange are written or dumped to a floppy disk or CD-ROM.
Ericsson’s support technicians load this disk into the AXE exchange;
initial loading is the name of this task.

In an AXE exchange, it is recommended to save program files and data
values at regular intervals. These system backup files make it possible to
reload the AXE exchange in an older state after a system fault. Reloading
data and programs is the name of this procedure.

During a system reload, some program variables receive values from the
backup file, while others do not. These variables may not receive values
until they are accessed in a subprogram. The designer determines the
behaviour of each variable using variable properties.

Chapter Objectives

After completing this chapter, you are able to:

• Describe the different types of loading

• Describe dumping

• Describe command logging

• Declare all variables correctly in a declare sector

• Describe the principles of function change

Plex-C 2

Initial Loading

Suppose a new AXE exchange is ready for action. The hardware is
installed and it is time for initial loading, that is, loading the programs and
initial data into the central processors. Initial data includes values of con-
stants (symbols) and initial values from the data sector.

The new software consists of all CP programs and initial data. Program
production engineers compile and generate the software and store on
floppy disk or CD-ROM. They load the disk into some test exchange.
After testing the fresh software until no more errors are found, the pro-
gram production engineers dump the test exchange memory contents to
another disk, the reference disk. Again, this disk consists of program code
and initial variable values set in the data sectors. These initial variable val-
ues are valid in all exchanges using this software.

Figure 3.2

Production of the reference disk

Now the Ericsson support engineers load the reference disk into the fresh
AXE exchange. On top of Plex programs and initial data, the exchange
needs subscriber, routing and hardware parameters too. These parameters
are known as exchange data. Normally the operator sets the exchange data
using commands. At initial start, however, this procedure would be too
time-consuming. Instead, Ericsson delivers standard default exchange data
on a floppy disk. Figure 3.3 shows that reference disk and exchange data
may arrive on separate disks, or on one CD-ROM called the working
dump.

Plex-C

Compiler

Programs and

Initial Data

Test
Plant

Dumping

Programs and

Initial Data

Reference Disk

Loading, Dumping and Variable Properties

Figure 3.3

Initial loading

The exchange technician performs initial loading on the stand-by/sepa-
rated (SB/SE) side of the CP. After the loading, the APZ starts automati-
cally. This means that the control system can receive and execute
commands routed to the APZ.

The exchange technician can now start the telephony part with command
SYATI. The APT is then ready to receive and execute commands.

When the exchange technician is finished with all commands towards the
stand-by side, it is time to order switching of CP sides. As soon as the
stand-by side becomes executive, the exchange performs an automatic sys-
tem restart. After the restart, the exchange is ready for its normal duties.

Dumping

After initial loading and several tests of the new exchange, the switch is
ready to operate. Before the exchange goes into traffic, it is time for a man-
ual dump. The exchange copies the contents of the main store to a file on a
hard disk in the file-management subsystem. This is a system backup copy
of the entire software, which is available for reloading, if the exchange
software goes faulty.

AXE

Exchange

Exchange Data

Working Dump

Reference Disk

with Exchange Data

Installation

New System

Reference Disk

Plex-C 2

Figure 3.4

Main store in the central processor

If the main store has sufficient storage capacity, it is possible to keep a
back-up copy of the PS and the DS in the MS. This function is known as
BUMS, back-up in main store. BUMS reduces the time for a system reload
from 15 to less than 3 minutes.

While the exchange is in operation, the exchange technicians perform
manual dumping using command SYBUP at regular intervals, e.g. once a
week. After changes to programs or relative addresses in PS or RS, as well
as other major changes such as file size alteration, the exchange technician
runs a manual dump too.

It is particularly important to dump some types of data regularly so that
their information is not lost in the event of a serious exchange failure.
Automatic dumps take care of this task.

These commands are available to dump memory contents.

SYBUP. Dumps the entire software to hard disk or main store (BUMS).

SYBUI. Initiates automatic data dumping, at times specified with SYBTS.

SYBTS. Specifies the times for automatic dumping.

There are two types of automatic data dumps, large and small dumps.

Program Store

Reference Store

Data Store

relative addresses

administrative info

programs and

corrections (object

code)

signal distribution

tables

constant values

variable values

backup (optional)

MS
Main Store

Loading, Dumping and Variable Properties

Large Data Dump

This dump includes all exchange-dependent parameters or exchange data.
These are the RELOAD-marked variables in the declare sector. Examples
for such variables:

•

Number of devices or records in a block with alterable file size

•

Parameters for routes, i.e. groups of telephone devices

•

Subscriber categories and parameters

Ericsson recommends saving a large data dump once a day during low
traffic, for instance, at 5 am.

Small Data Dump

This section only applies to exchanges with pulse meter charging. Charg-
ing information, in this case call meter values, is most important to a tele-
com operator. Therefore charging parameters are saved several times a
day, or even several times an hour in large international exchanges. This
dump is called the small data dump.

Blocks with variables participating in the small data dump need the block
characteristic BCLOGDATA. Mark these variables with the macro
RELOAD in the program sector. Syntax:

RELOAD VARIABLE variable1, VARIABLE variable2 ...;

The Plex-C compiler expands the macro into program code handling the
necessary signal communication. See reference [2].

Note that exchanges using toll-ticketing charging write the charging data
directly from the CP to the hard disk, not using the small data dump.

Dump Handling

The hard disks in the file-management subsystem contain the files for the
data dumps. Two groups of files exist.

FFR.

First File Range. Contains the first 100 backup files. This group

contains the latest files which may be unreliable in case of serious system
disturbances.

SFR.

Second File Range. Contains the next 28 backup files. The use of

SFR is optional. These backup files can be more reliable and exist as a
backup in case of unsuccessful reload attempts from FFR.

See Figure 3.5.

Plex-C 2

Figure 3.5

Backup files

File RELFSW0 contains the latest backup file. In case of an automatic
reload, the system uses the data in file RELFSW0. Each backup file
RELFSWn consists of six subfiles R0, R1, to R5. Figure 3.6 shows the
example of file RELFSW0.

Figure 3.6

Subfiles in backup file RELFSW0

R0.

This subfile contains control data for administering the other sub-

files, such as information indicating the subfiles to be loaded in the event
of a reload.

R1/R2. These subfiles contain the latest small data dumps, mostly charg-
ing data. Only relevant with pulse metering. The dumping operation over-
writes the older subfile first.

RELFSW0

RELFSW1

RELFSW99

RELFSW100

RELFSW101

RELFSW127

FFR

First File Range

SFR

Second File Range

Backup File RELFSW0

Control
Data

Charging
Data

Exchange Data
RELOAD marked
variables

Contents of
PS and RS

Loading, Dumping and Variable Properties

R3/R4. These subfiles contain the latest large dump dumps, mostly
exchange data, that is, RELOAD-marked variables. The dumping opera-
tion overwrites the older subfile first.

R5.

This subfile contains a copy of the PS and RS taken at manual

dumps. R5 is always loaded at reload.

The operator commands SYBTS and SYBUI make it possible to initialise
automatic dumping. Then, the exchange generates small and large data
dumps automatically at regular intervals.

Reloading

After a serious disturbance in an AXE exchange, the system may start a
reload with restart. The exchange loads the values of all RELOAD
declared variables from subfiles R5, R1 or R2, and R3 or R4. If BUMS is
active, the exchange technician may remove R5 or R1/R2 from the reload.
Depending on the cause of the reload, AXE supports manual and auto-
matic reloading.

Manual Reloading

Use this exchange command to manually reload and restart the entire
switch.

SYREI:RANK=RELOAD;

After reloading the exchange data, the system restarts automatically. See
Chapter 7, Software Recovery, for more details.

Automatic Reloading

Repeated serious faults lead to unproductive program execution. Three
consecutive faults of this type, within a certain time interval set by com-
mand, initiate an automatic reload.

The first reload always uses the latest backup file, RELFSW0. In case file
RELFSW0 is faulty, the exchange may offer an automatic selection of an
older reload file.

The file-management subsystem stores the automatic dumps in the subfiles
of RELFSW0. Consider the situation in Figure 3.7 where the lightning
symbol indicates a reload and restart of the exchange. In this situation, the
latest small data dump is in subfile R1 and the latest large data dump is in
subfile R4.

Plex-C 2

Figure 3.7

Automatic dumping and reloading

Now for the $1000 question! Which subfiles are participating in the auto-
matic reload?

The answer is subfiles R1, R3, and R5. Here is why.

R1.

Take the latest charging data dump to lose as little money as pos-

sible. Any faulty values in subfile R1 would not damage the traffic han-
dling.

R3.

Take the older, more reliable exchange data dump. Chances are

that the latest subfile, R4, contains a data fault that caused the reload. R4
may have been dumped only a couple of seconds before the reload.

R5.

Loads an older version of the entire software. If BUMS is active,

reloading subfile R5 is optional.

Loading subfile R3 means losing the latest changes to the exchange data.
Command logging makes it possible to solve this problem.

Command Log

There are two ways to set or change exchange-specific parameters.

•

Operator commands. The system copies these commands to a com-
mand log file to trace and repeat the commands.

•

Subscriber service. Example: the subscriber orders a wake-up call in
the exchange. The system translates the subscriber service into com-
mands and stores the commands in the command log file.

Some operator commands are more important than others. For instance,
printout commands are not critical, because they do not change any
exchange data. Only commands that change the values of RELOAD
declared variables are saved in command log files to trace and to repeat the
commands.

The exchange makes it possible to reload the command log file by com-
mand IOCMI or automatically, at a system reload with restart.

Reload

Time

Loading, Dumping and Variable Properties

The command log consists of subfiles numbered 0 to 9,999,999. After
every large data dump, the system opens a new command subfile with the
number incremented by one.

Figure 3.8

Loading command log subfiles

Suppose a serious fault requires a system reload with restart, as in Figure
3.8. The system loads subfile R5, the manual dump of the entire software.
Next, the APZ loads the latest charging data from subfile R1 or R2. Then,
the system loads the second latest exchange data values from subfile R3.
Finally, the APZ re-runs the latest commands changing exchange data
from command log subfiles clog18 and clog19.

Program Characteristics for Command Logging

Not all AXE commands require logging, that is saving in command log
subfiles. Only those AXE commands which set or alter exchange data need
to take part in command logging. How does the APZ know which AXE
command to log and which not?

Each AXE command has a set of characteristics known as the command
category number or COCA number. See Chapter 5, Commands, for details.
The COCA number consists of 16 bits, one of them, bit 14, is set to 1 if the
command requires logging. When the IO system receives an operator com-
mand, it looks into the Plex program handling the command to find out if
the COCA number has bit 14 set. If so, the IO system copies the operator
command to the current command log subfile.

A similar approach applies to subscriber services. Here, the telephone sub-
scriber can directly influence exchange data from a telephone. The SW
unit in the Subscriber Services Subsystem (SUS) analyses the subscriber
input and translates it into a command on the command log subfile.

Variable Properties

This section discusses the various variable properties in greater detail.
Consider the overview in Figure 3.9.

Error causing

Time

reload

command log subfiles

manual dump

R5
R1 or R2
R3
clog18 + clog19

Plex-C 2

Figure 3.9

Data types and variable properties

Temporary variables. Value put in register memory only. Temporary
variables are undefined, unless they receive a value in an ENTER-to-EXIT
routine. If temporary variables have a value, they lose it at the next EXIT,
I/O statement or combined signal sending statement. Speed is the major
advantage of temporary variables.

DS. Value permanently stored in data store. Disadvantages: fairly slow
and use of memory space.

BUFFER. Dynamically allocated in data store. In other words, BUFFER
variables are only available when the program reserved space in the data
store with Plex statement ALLOCATE. Disadvantage: very slow. Advan-
tage: BUFFER variables allow access from several different SW units.

Use BUFFER variables when the program uses file-oriented input-output
statements.

CLEAR. CLEAR-marked variables receive the value 0 at all types of
start and restart routines. Efficient microprograms perform this task; it is
not common to set any variables to 0 in the data sector or the restart sub-
program in the program sector, both alternatives are too slow. CLEAR
resets even symbol and string variables to 0 at restart. Note that the control
system automatically releases all BUFFER variables at restart, hence the
property combination BUFFER CLEAR does not make much sense. In
fact, it is illegal.

RELOAD. Exchange-dependent parameters are RELOAD-declared vari-
ables in the Plex program. Only operator commands or some subscriber
service can change the values of these variables, but not the SW unit on its
own initiative! These variables are always part of the large dump, and they
are reloaded into the exchange at any reload with restart.

A typical example for a RELOAD-marked variable is CINDNUM, the
number of individuals in a file of records with size alteration. Only the
exchange technician can increase or decrease the number of records, not
the SW unit on its own initiative.

CLEAR

RELOAD

DUMP

STATIC

Field Variable

Symbol Variable

String Variable

Temporary

BUFFER

Loading, Dumping and Variable Properties

DUMP. At a system restart, the exchange prints out relevant internal data
including all DUMP-marked variables. This printout can help to analyse
the cause of the system disturbance. Variables can also receive the DUMP
property later by operator command. Very few variables have the DUMP
property. And this is a hint for the exercise!

STATIC. STATIC-declared variables are not transferred from old to new
version of a SW unit at function change. You do not need to worry about it
at this stage. See page 36 in this chapter for more information.

R. These variables depend in size on the register size of the target proces-
sor. The value range of an R variable is unpredictable at programming
time, and many restrictions apply to them. See reference [4].

Table 3.1 compares the access times for different types of variables, see
also reference

[3]

. Always give preference to temporary variables if the

program is time-critical.

Table 3.1

Typical access times per variable type

Table 3.2 lists all possible combinations of variable properties. Each check
mark (

✔

) indicates a valid combination. Table based on reference [5], see

also [6].

Variable type

APZ 211 11

one access

APZ 212 11

one access

Temporary

0.16

0.2

Common DS

0.81

0.4

Structured

0.98

0.5

Record

0.98

0.5

Indexed

0.98

0.6

Indexed 2-dimensional

1.14

1.1

Dynamic buffer

6.75

2.3

Plex-C 2

Table 3.2

Valid combinations of variable properties

Function Change

Function change is a process replacing old versions of SW units with
newer versions in a running AXE exchange. Function change also allows
to add new SW units to the existing software.

When replacing software units, the exchange copies all variable values
from the old to the new program versions. The exchange does not transfer
values of STATIC declared variables, though.

STATIC variables

Declare a variable in the new version of the program as STATIC if the var-
iable value from the old program version shall not be copied. This is useful
for all variables receiving initial values in the data sector. If these variables
were not STATIC declared, the old variable value overrode the value from
the new data sector. If the variable is STATIC declared, the value from the
new data sector applies.

Example

Variable CDATA has value 42 in the old software. The exchange techni-
cian replaces the program with new software. The new program sets
CDATA to 10 in the data sector. If the designer did not declare CDATA as
STATIC, the function change procedure would overwrite the start value 10
and copy the old variable value, 42, into CDATA.

Variable type

Field var./

integer

Symbol var./

enumeration

String

variable

DS
DS DUMP
DS STATIC

✔
✔
✔

DS RELOAD
DS RELOAD DUMP
DS RELOAD STATIC

✔
✔
✔

DS CLEAR
DS CLEAR DUMP

✔
✔

not recom-

mended

BUFFER
BUFFER DUMP

✔
✔

no
no

Temporary

✔

Loading, Dumping and Variable Properties

Changing the Data Structure

If new and old program versions have different data structures, it is neces-
sary to load conversion tables to rearrange the data in the reference and the
data stores. Rearranging the data structure takes a considerable amount of
time during function change, and the designer of a new program version
should try to avoid changing the existing data structure more than neces-
sary.

Furax and Fuspel

Furaxtool produces these conversion tables needed in function change.
Furax is an acronym for Functional Replacements in AXE systems. Furax-
tool is available in APStools. The input to Furaxtool is a DCI document,
data change information. The designers write these documents in FUS-
PEL, the Function Revision Specification Language. Furaxtool also
includes an editor and syntax checker for DCI documents.

See Figure 3.10 for details. Note that exchange command FCTAL loads
the FC conversion tables into the data store of both CP sides.

For more information on Furaxtool see reference [7], while reference [8]
has a complete description of DCI documents and their syntax.

Figure 3.10

Furaxtool

DCI Syntax

Consider the DCI document in Figure 3.11 to Figure 3.13. The DEFINE
section declares the old and new unit product number, declares internal
counters for loops in the DCI, declares local temporary DCI variables and
sets the size of record files.

Furaxtool

DCI

DCI editor
FUSPEL syntax check

generates FC
conversion tables

FC conversion
tables for all SW
units being replaced

PS RS DS

CP-A

CP-B

FCTAL command
to load conversion
tables

Plex-C 2

The CONVERSION section sets initial values for DS variables. Consider
this example.

FOR ALL P DO

FOR ALL I FROM 0 UNTIL 31 DO

P:N.ARRAYPOOL(I) = 0;

This DCI statement sets the first 32 elements in variable ARRAYPOOL to
0 in all records. N. marks the new version of the variable. Here is another
example.

N.CGSINLET = O.CGSINLET;

This DCI statement ensures that common variable CGSINLET keeps its
value, in other words, the operating system transfers the variable value
from the old to the new program version. O. marks the old version of the
variable. Finally, a last example.

NOASSIGN N.CCREF;

Variable CCREF does not receive any initial value after the function
change. It is common to use NOASSIGN for new variables in the new pro-
gram version, in other words, for variables which did not exist in the old
program version.

Loading, Dumping and Variable Properties

Figure 3.11

Data Change Information for GSM block MALT (Part 1)

DOCUMENT MALTUCHANGE1;

THIS DCI SUPPORTS THE FUNCTION CHANGE FROM:

CMS40-SS-PH1 CN-P0 TOWARDS CMS40-SS-PH2 CN-P0

1 DEFINE SECTOR

1.1 NEW STATEMENT

1.2 OLD STATEMENT

1.3 COUNTER & LOCAL STATEMENT

1.4 FILE SIZE STATEMENT

2 CONVERSION SECTOR

2.1 RECORDS

2.2 COMMON STORED VARIABLES

1 DEFINE SECTOR

---------------

DEFINE;

1.1 NEW STATEMENT

-----------------

NEW N CAAZ 107 1949, REV D;

1.2 OLD STATEMENT

-----------------

OLD O CAAZ 107 1296, REV F;

1.3 COUNTER & LOCAL STATEMENT

---------------------

COUNTER P,I;

1.4 FILESIZE STATEMENT

----------------------

! SAE = 500 !

FILESIZE OF N.DEVDATA =

FILESIZE OF O.DEVDATA;

! SAE = 504 !

FILESIZE OF N.ROUTEDATA =

FILESIZE OF O.ROUTEDATA;

END DEFINE;

2 CONVERSION SECTOR

-------------------

Plex-C 2

Figure 3.12

Data Change Information for GSM block MALT (Part 2)

2 CONVERSION SECTOR

-------------------

CONVERSION;

2.1 RECORDS

---------------

FOR ALL P DO

P:N.ALARMSTATE = 0;

FOR ALL P DO

FOR ALL I FROM 0 UNTIL 31 DO

P:N.ARRAYPOOL(I) = 0;

FOR ALL P DO

P:N.FLCONNFID = 0;

FOR ALL P DO

P:N.GSINLET = P:O.GSINLET;

FOR ALL P DO

P:N.IDLEPATSTATE = P:O.IDLEPATSTATE;

FOR ALL P DO

P:N.LENGTHPOOLNUMLIST = 0;

FOR ALL P DO

P:N.LINKBRTE = #FFFF;

FOR ALL P DO

P:N.LINKFRTE = #FFFF;

! POOL NUMBER ASSOCIATED TO THE ROUTE IS SET TO 1 !

FOR ALL P DO

P:N.MIS1 = 1;

! CHARACTERISTIC OF THE ROUTE IS SET TO FULL RATE = 1!

FOR ALL P DO

P:N.MIS2 = 1;

FOR ALL P DO

FOR ALL I FROM 0 UNTIL 31 DO

P:N.POOLISTPTR(I) = 0;

FOR ALL P DO

P:N.RFLAGMIS1 = 0;

FOR ALL P DO

P:N.RFLAGMIS2 = 0;

FOR ALL P DO

P:N.SAVEPTR = 0;

FOR ALL P DO

P:N.TAPOOLINDEX = 0;

2.2 COMMON STORED VARIABLES

---------------

N.CGSINLET = O.CGSINLET;

NOASSIGN N.CCREF;

NOASSIGN N.CDIRECTION;

NOASSIGN N.CFLSTATUS;

NOASSIGN N.CIND;

Loading, Dumping and Variable Properties

Figure 3.13

Data Change Information for GSM block MALT (Part 3)

Chapter 6.5, Function Change Compatibility, in the Software Reliability
Handbook contains useful hints for all designers needing to update the
data structure of an existing block. See reference [6].

Function Change Procedure

In this procedure, an exchange technician replaces the old code of some
SW units with new Plex-C programs. The new software includes the new
object code as well as the FC conversion tables for handling the variables.

Two different methods exist to update software: function change (FC)
method 1 and method 2. Method 1 causes less disturbances to the running
exchange, but cannot replace more than 256 SW units. Some information
on these methods appears in reference [9]. Details about the commands
and printouts can be found in the operational instruction in reference [10].

Function Change Method 1

Figure 3.14 lists the important steps for FC method 1.

2.2 COMMON STORED VARIABLES

---------------

N.CGSINLET = O.CGSINLET;

NOASSIGN N.CCREF;

NOASSIGN N.CDIRECTION;

NOASSIGN N.CFLSTATUS;

NOASSIGN N.CIND;

NOASSIGN N.COWNNUMBER;

NOASSIGN N.CPOOLCOMPLISTINDEX;

NOASSIGN N.CRATETYPE;

NOASSIGN N.CTEMPORARYAREA;

NOASSIGN N.CTYPESELECTION;

END CONVERSION;

*END;

ID MALTUCHANGE1 TYPE DOCUMENT;

CLA 1/10926;

NUM CAAZ 107 1949;

REVISION D;

DATE 1996-03-04;

DES MET/T/RDE SJS;

RES MET/T/RD;

APP MET/T/RDE (FCH);

END ID;

Plex-C 2

Figure 3.14

Function change method 1

Step 1. The exchange technician loads the new Plex programs simultane-
ously in both CP sides. The new software remains passive.

Figure 3.15 shows the effects of command FCSUL. The command loads
the new programs and the new initial data set in the data sector. Note that
the active software is marked with

, the passive software is marked with

Command FCSUL

Load new Plex programs in
both CP sides

Command FCTAL

Load FC conversion tables in
both CP sides

Command FCSUC

Activate new Plex programs in

executive CP side

Various

Test the AXE exchange with
the new software in exec. CP side

Command DPPAI

Raise the AXE exchange to
parallel mode again

Small system restart

Transfer variable values from

old software in standby CP side

to new software in exec. CP side

Loading, Dumping and Variable Properties

Figure 3.15

Method 1, step 1: loading the new software

Step 2. The exchange technician loads the FC conversion tables simulta-
neously in both CP sides. The conversion tables make it possible to trans-
fer the data structure from old to new software and tell the operating
system to set initial values for the variables.

Step 3. The exchange technician activates the new software with com-
mand FCSUC. See Figure 3.16. Remember that

is for active, and

for passive. The command causes a small restart and separates the CP
sides. The new software is now active in the EX CP side.

Meanwhile, the SB/SE CP side keeps the old software in active state.
Thus, the exchange can quickly return to the old software, should the new
software be faulty. In case of a fault in the new software, the APZ automat-
ically returns to the old SW configuration by switching CP sides and gen-
erating a large restart.

After activating the new software, the operating system assigns initial val-
ues to all DS variables, as specified in the DCI/FC conversion tables. For
unchanged variables, the system copies the value of the old SW to the new
SW. Variables declared as STATIC in the new software do not receive the
value from the old SW. Here, the value is usually set in the data sector of
the new Plex program. See “STATIC variables” on page 36.

old software

new software

CP main stores

old software

new software

CP main stores

SB/WO

Central Processors

New Plex
object code

Command FCSUL

Plex-C 2

Figure 3.16

Method 1, step 3: activating the new software

Step 4. Test the new software in the AXE exchange.

Step 5. If the tests are successful, raise the central processors to parallel
mode using command DPPAI. Both CP sides execute the same, new SW.

The exchange technician may load new exchange data once the new soft-
ware is active and running.

Function Change Method 2

This method is more complex and takes more time than method 1. How-
ever, method 2 can replace an unlimited number of SW units. Furthermore,
method 2 enables the exchange technician to load new exchange data
before activating the new Plex programs.

Figure 3.17 provides a brief overview of method 2. The survey is by no
means complete, but includes the most important stages. Please do not
attempt to memorise the command names, they appear as side information
only.

old software

new software

CP main stores

old software

new software

CP main stores

SB/SE

Central Processors

Command FCSUC

Loading, Dumping and Variable Properties

Figure 3.17

Function Change Method 2

Step 1. The exchange technician separates the CP sides using command
FCSEI. The system restarts the SB/SE CP side. The exchange technician
connects this CP to the IOG devices for loading new software.

Step 2. The exchange technician passivates the old program versions with
command LABSC (not shown in Figure 3.17) and removes the old soft-
ware from the SB/SE CP side using command LASUR.

Command FCSEI

Separate CP sides
Restart standby CP side

Command LASUR

Remove old SW units from
standby CP side

Command LASUL

Load new object code in
standby CP side

Command FCTAL

Load the FC conversion tables
in standby CP side

Command FCDAT

Transfer file sizes, data and
RP/EMRP SW from the exec. CP

Connect standby CP side to IOG
devices for loading new software

Various

Set any exchange data to start
values in standby CP side

Command FCSWI

Switch CP sides, the new SW
is active

Command DPPAI

Raise the AXE exchange to
parallel mode again

side to the SB/SE CP side

Transfer variable values from
old software in standby CP side
to new software in exec. CP side

Lose all calls due to large restart

Plex-C 2

Step 3. The exchange technician loads the new object code in the SB/SE
CP side using command LASUL. See Figure 3.18.

Figure 3.18

Method 2, step 3: loading the new software

Step 4. The exchange technician loads the FC conversion tables in the
SB/SE CP side using command FCTAL.

Step 5. Using command FCDAT, the exchange technician transfers file
sizes, data and RP/EMRP software from the old software to the new soft-
ware in the SB/SE CP side.

Step 6. Using various commands, the operator can set certain exchange
data to initial values in the SB/SE CP side. The exchange technician gives
these parameters the STATIC property using command LAVCS. The
STATIC property prevents the new initial variable values from being over-
written with the old values in step 7.

Step 7. Using command FCSWI, the exchange technician takes the new
software into operation. This comprises three actions:

−

Transfer variable values from old software to new software in
the SB/SE CP side, except for STATIC declared variables.
During the transfer, the exchange rejects new call attempts.

−

Switch CP sides, the new software is now in the CP in state EX

−

Switching CP sides includes a large system restart. The
exchange loses all call attempts and active calls.

old software

CP main stores

new software

CP main stores

SB/SE

Central Processors

New Plex
object code

Command LASUL

Loading, Dumping and Variable Properties

For information on STATIC, see “STATIC variables” on page 36. Figure
3.19 shows the CP sides after the switch-over.

Figure 3.19

Method 2, step 7: activating the new software

Step 8. The exchange technician tests the behaviour of the new code. If
the AXE exchange operates without any trouble, the exchange technician
brings the central processors back to parallel mode using command
DPPAI. The operating system replaces the remaining old software with the
new object code from the EX CP side.

If the AXE exchange does not operate successfully, the exchange techni-
cian can return to the old code left in the SB/SE CP side using restart com-
mand SYREI in the executive side.

old software

CP main stores

SB/SE

new software

CP main stores

Central Processors

Command FCSWI

Plex-C 2

Comparison: Method 1 versus Method 2

The following table lists advantages and disadvantages of both function
change methods. Method 1 loads the new program code into the program
store in addition to the existing old software. Since the PS capacity is lim-
ited, method 1 can only replace 16 SW units at one time. Method 2
removes the old software when loading the new code.

Furthermore, method 1 does not support replacement of central SW units
in the APZ.

Table 3.3

Comparing both methods for function change

Criterion

Method 1

Method 2

Number of SW units

256

unlimited

Central SW units in APZ

cannot be replaced

may be replaced

Complexity

low

high

Time needed

little

rather much

Rank of restart

small

large

Active calls affected

calls interrupted

Handling of exchange data

must be loaded
after activating

new software

may be loaded

before activating

new software

Loading, Dumping and Variable Properties

Chapter Summary

Remember these points from this chapter.

Figure 3.20

Summary

• RELOAD-marked variables contain exchange data. The

exchange saves these variables in the large dump and charging
data in the small dump.

• The file-management subsystem can put dumps on the hard-

disk or to the back-up area in the data store.

• Purpose and use of command logging.

• Variable properties RELOAD, CLEAR, DUMP, STATIC and

their combinations.

• Variable types DS, BUFFER and temporary; advantages and

disadvantages. Use BUFFER variables only in exceptional
cases.

• The DCI document is essential to prepare the data transfer dur-

ing function change in a running AXE exchange.

Plex-C 2

References

[1]

AXE 10 Survey,
EN/LZT 101 1513 R2A,
© Ericsson Telecom AB 1995

[2]

Output of Reload Information (DR)
ETX 102 60-1437 Uen
© Ericsson Utvecklings AB 1997

[3]

AXE System Characteristics Handbook
especially Chapter 5, Designing Capacity-Efficient Software
EN/LZB 101 1978-1
© Ericsson Telecom 1995

[4]

Updating of Software Units with R Variables (DR)
ETX 102 60-1060
© Ericsson Telecom 1993

[5]

Plex-C Language Description
especially Chapter 6, Variable Properties
EN/LZB 101 1903 R2A
© Ericsson Telecom 1994

[6]

Software Reliability Handbook, Edition 4,
EN/LZG 205 603
© Ericsson Telecom 1996

[7]

Furaxtool User’s Guide
1/198 17 - CAA 139 1100 Uen
© Ericsson Telecom 1995

[8]

Data Change Information, document instruction
2/1013-FCK 114 22
© Ericsson Telecom 1994

[9]

System Start and Restart in AXE 10 (DR)
ETX 102 60-1114 Uen
© Ericsson Utvecklings AB 1996

[10] Function Change, Exchange of Central Software Units (OPI)

2/154 31-ANZ 211 12 Uen
© Ellemtel 1989

Chapter 4

CP-CP Unit Interaction

Introduction

Communication between two CP SW units can be difficult when sending
multiple signals. The sending unit needs to find out the address or block
reference of the receiving block, and whether this block has an ENTER
statement for the signal. This chapter discusses some solutions to these
problems.

Figure 4.1

Chapter Objectives.

Signal Communication

Two basic types of signals are relevant for this chapter, unique and multi-
ple signals. See Figure 4.2.

Figure 4.2

Unit communication: unique and multiple signals

Chapter Objectives

After completing this chapter, you are able to:

• Describe difficulties when sending multiple signals

• Describe block characteristics

• Determine block type and block type extension for a unit

• Apply function codes

• Describe dynamic links between units

• Describe optional function blocks

Unit A

Unit B

Unit A

Unit B

Unit C

Unit D

A Unique Signal

A Multiple Signal

Plex-C 2

Unique signals cause no difficulties. The sending program does not need to
know the address or block reference of the receiving block. The sending
program can also be sure that the receiving block has an ENTER statement
for this signal.

Multiple signals, on the other hand, are less convenient. Plex programs
may send multiple signals to any block in the entire exchange. Consider
these problems:

How to find the block reference of the receiving block?

Sending a multiple signal, the sending SW unit must make sure that
the receiving program has an ENTER statement for this signal in the
program sector. Otherwise, the operating system would not know
where to continue and might cause a system restart.

Multiple Signal Sending

Consider the following fictitious example of an operator command.

BLODI:DEV=HELLO-1&&-5;

This command blocks telephone devices in the block specified. In this
case, the operator wants to block devices 1 through 5 in block HELLO.
Block BLOC receives and handles the command BLODI. SW unit
BLOCU needs to send multiple signal SMBLOC to unit HELLOU to
block the devices.

Unit BLOCU has to solve two problems: how to find the block reference
of block HELLO and to check if this block accepts signal SMBLOC at all.

Finding Block References

There are three basic ways to attack the first problem of finding a block
reference.

Solution 1. If two SW units exchange several signals, it is common to
start with unique signals. Both units send their own block reference with a
unique signal and the receiving block stores the partner block’s reference
for sending multiple signals later-on. Consider Figure 4.3.

Does solution 1 help unit BLOCU? No. Unfortunately, BLOCU cannot
send unique signals to all blocks in the exchange to prepare for multiple
signal sending. Apart from our example, though, this solution is rather
common.

CP-CP Unit Interaction

Figure 4.3

Units A and B exchanging block references

Solution 2. All blocks have certain properties known as block characteris-
tics. Each SW unit has two global number symbols, block type and block
type extension, which collect these block characteristics in two 16 bit
words. When looking for a SW unit with certain properties, some signals
to APZ service block LARI deliver the block number for a given block
type. Consider the signals in Table 4.1.

Table 4.1

Important signals in unit interaction

Signal

Unit 1

Unit 2

Signal Data

NOFORTYPE

user

LARI

block type

NOFORTYPEACK

user

LARI

block number

TYPEFORNO

user

LARI

block number

TYPEFORNOACK

user

LARI

block type

block type extension

NOFORNAME

user

LARI

block name

NOFORNAMEACK

user

LARI

block number

block type

NOFORFUCODE

user

LARI

function code

NOFORFUCODEACK

user

LARI

block number

CHKFUCODE

user

LARI

block number
function code

CHKFUCODEACK

user

LARI

yes or no

MULTIPLESIGNAL3
REFERENCE UNITBREF
WITH ...

Unit A

Unit B

SEND

ENTER

SEND

ENTER

UNIQUESIGNAL1
WITH UNITAREF, ...

MULTIPLESIGNAL4
REFERENCE UNITAREF
WITH ...

ENTER

SEND

ENTER

MULTIPLESIGNAL2
REFERENCE UNITAREF
WITH ...

Plex-C 2

All signals in Table 4.1 are combined signals. Mind that these signals send
the block number, not the block reference. Use Plex-C procedure TRANS-
FORM to translate between block number and block reference and vice
versa. See Chapter 7 in reference [6].

The combined signal pair NOFORTYPE/NOFORTYPEACK is particu-
larly interesting. Using these signals, APT programs can ask block LARI
for the block number for a given block type.

In our example, unit BLOCU would use signal pair NOFORNAME/
NOFORNAMEACK to find the block number, and, eventually, the block
reference of block HELLO.

Solution 3. In addition to block characteristics, SW units use function
codes to identify important properties. Each SW unit can use several out of
approximately 330 function codes today. To find a block with a particular
function code, send signal NOFORFUCODE to LARI. See Table 4.1
above.

Signal Acceptance

Now for the second problem. Does a particular CP program receive a cer-
tain signal? In our example, does unit HELLOU have an ENTER state-
ment for signal SMBLOC? There are two alternatives to tackle this
situation.

Solution A. The user program checks the block characteristics in block
type and block type extension of the relevant program. The program
checks with block LARI sending signal TYPEFORNO to receive block
type and type extension. See Table 4.1 above.

In our example, unit BLOCU checks if block HELLO features the block
characteristics for telephony devices. The exchange technician can always
block such devices, and, consequently, unit HELLOU must accept multi-
ple blocking signal SMBLOC.

Solution B. The user program checks the function codes of the relevant
program. Function codes are always connected to a certain set of signals.
If a block has a particular function code, it must receive and send the cor-
responding signals listed in the design rule. See reference [2].

CP-CP Unit Interaction

Figure 4.4

Checking function codes

In our example, unit BLOCU checks if block HELLO has the function
code FCMANBLOC permitting manual blocking of the block’s devices.
Blocks with this function code must receive blocking signal SMBLOC.

BLOCU sends signal CHKFUCODE to LARI with the number for
FCMANBLOC, that is, 56. LARI replies with yes, the block has this func-
tion code, or no, it does not, in backward signal CHKFUCODEACK.

Block Type and Block Type Extension

Each block has certain properties described in block characteristics. Each
SW unit has two global number symbols, block type and block type exten-
sion, which collect these block characteristics in two 16 bit words.

Figure 4.5

Block type and block type extension

• The user program sends combined signal CHKFUCODE with

block number and interesting function code to block LARI.

• The acknowledgement signal, CHKFUCODEACK, informs the

user program if the block has the specified function code or not.

User Block

Wants function code

SEND

Traffic subprogram

ENTER

Block LARI

Answers yes or no

SEND

CHKFUCODE WITH

BLOCK NUMBER

CHKFUCODEACK

information

FUNCTION CODE

Checks requested

ENTER

code in internal table

WITH ANSWER

• Block Type Extension: properties applicable to all AXE blocks

• Block Type: different properties for APT and APZ blocks

• Declare both as global number symbol in declare sector

• Names for sample block FOO: BTFOO and BTEXTFOO

• Example for declaration

GLOBAL NSYMB BTFOO (65535);
GLOBAL NSYMB BTEXTFOO (65535);

• Set value in (source) parameter list

• Use special keywords TYPE and TYPEEXT in (source) parameter

list to identify these parameters to the compiler

Plex-C 2

The name of a block type consists of BT and the block name. The name of
a block type extension consists of BTEXT and the block name.

Each bit in block type and type extension corresponds to a certain block
characteristic. Several design rules list and describe these properties. Take
a look now at references [7], [8], [9] and [10].

Looking at these prehistoric documents, try to avoid a mental breakdown.
An update of these documents is on its way - alas, not in time for this
smashing piece of course literature. Never mind the irony here.

Reference [7] provides general information on the subject. The design rule
also describes how to check if a block type or block type extension
includes a certain block characteristic.

Reference [8] lists the various block characteristics starting with the char-
acteristics for the type extension, followed by the APZ block type and the
APT block type characteristics. Do not try to understand all the block
characteristics. Probably nobody does. Table 4.2 shows the most important
characteristics for the block type extension. The third column provides
unofficial, simplified and possibly faulty explanations.

Table 4.2

Important AXE block characteristics for block type extensions

Similarly, Table 4.3 describes some crucial characteristics available in
APT block types. Again, the third column is probably not related to the
true meaning of the characteristics. So, do not blame this book.

Block characteristic

Property symbol

Unofficial explanation

Command reception

BCCOMREC

Block receives some

MML commands

RP/EM control

BCRPEMCONT

Block uses RP or EMRP

programs

Block with variables in
the DS dump

BCLOGDATA

Program has exchange

data, RELOAD-declared

variables

Extensible files

BCEXTREC

Program has size altera-

ble files of records

CP-CP Unit Interaction

Table 4.3

Important APT block characteristics for block types

Looking at the list, note the strange lines and brackets in the column
Remarks. This explains which characteristics are incompatible with oth-
ers. Furthermore, remember: all these APT characteristics have no rele-
vance to an every-day software-only block. They usually have block
characteristic BCAPT and that is all.

Reference [9] shows the possible combinations of block characteristics in
a semi-graphic format. Figure 4.6 provides a part of this document, but
bear in mind that the information in the figure may no longer be up-to-date
by the time you are reading this.

Block characteristic

Property symbol

Unofficial explanation

APT

BCAPT

It is an APT block.

APT hardware

BCAPTHW

The block has hardware

units, and, consequently,

an RP software unit too.

Telephony device

BCTELDEV

The block has devices

which are not necessarily

implemented in hard-

ware.

Routes

BCROUTE

The block participates in

a route which is some

group or connection of

devices.

Subscriber line

BCSUBLI

The block has equipment

establishing the connec-

tion to the telephone sub-

scriber. In other words, it

is usually block LI.

Plex-C 2

Figure 4.6

Structure of block characteristics

For AXE block type extensions, all combinations of block characteristics
are possible. For block types, however, this is not true. Blocks can either
have the characteristic BCAPZ or BCAPT, not both. APT blocks may
either set characteristic BCTELDEV or BCSWITCH, not both. The
greater than symbols (>) have the same interpretation: switching equip-
ment, for instance, can be either analog or digital, which is not really that
surprising.

Finally, check out reference [10]. This document lists the numeric values
of the various block characteristics. For each property, two values appear:
the block characteristic, for example, BCAPT, and the masking symbol,
for example, BMAPT. Use BCAPT to determine the block type of a block.
Use BMAPT when testing whether a given block type includes a certain
characteristic. This is explained below. Table 4.4 shows some popular
block characteristics and their hexadecimal values.

AXE-level

BCCOMREC

BCRPEMCONT

BCLOGDATA

BCLOGINFO

BCEXTREC

BCLOCSTART

BCEXTALARM

BCINDSEL

APZ-level

APT-level

BCAPZ------------------------------------------------ BCAPT

BCNOTREMOVE

BCAPTHW

BCANSI

BCCATOWN

BCOID

BCTELDEV-------------------------------------------BCSWITCH

BCIODEV

BCSEMIPERM

>BCANALOG

BCFILE

BCDIGDEV

>BCDIGITAL

BCALFA

BCROUTE

BCINPUT

BCROUTING

BCOUTPUT

BCINCOM

BCBLOCKED

BCOUTGO

CP-CP Unit Interaction

Table 4.4

Hex values for selected block characteristics

Sometimes BC and BM symbols have the same value, sometimes they do
not. This is one of the fascinating mysteries of AXE programming.

Block Type Example

Consider fictitious block FOO. This APT block has exchange data, record
files with size alteration and software-only telephony devices.

In other words, these four block characteristics apply.

•

Block Type Extension: BCLOGDATA and BCEXTREC

•

Block Type: BCAPT and BCTELDEV

Calculate block type and type extension using the binary OR operator (+).

•

BTEXTFOO = BCLOGDATA (+) BCEXTREC
! NUMERIC RESULT: #2400 !

•

BTFOO = BCAPT (+) BCTELDEV
! NUMERIC RESULT: #8400 !

Code in Parameter List

Continuing the example, consider the resulting code in the parameter and
source parameter list documents. See Figure 4.7.

Block

characteristic

BC symbol

Value

BM symbol

Value

Command
reception

BCCOMREC

4000

BMCOMREC

4000

Block with varia-
bles in the DSdump

BCLOGDATA

0400

BMLOGDATA

0400

Extensible files

BCEXTREC

2000

BMEXTREC

2000

APT

BCAPT

8000

BMAPT

8000

APT hardware

BCAPTHW

9000

BMAPTHW

9000

Telephony device

BCTELDEV

8400

BMTELDEV

8400

Routes

BCROUTE

8500

BMROUTE

8500

Subscriber line

BCSUBLI

8402

BMSUBLI

860E

Plex-C 2

Figure 4.7

Defining block type and type extension in the parameter list

DOCUMENT FOOUSPARAM;

! 190 73-CAA1070000 SOURCE PARAMETER LIST

CREATED : 1997-02-27 REV. X BY ETX/TK/XD SBRT

SOURCE PARAMETER LIST

-----------------------------------------------------------------------

BLOCK DESIGNATION

-----------------------------------------------------------------------

BLOCK FOO;

-----------------------------------------------------------------------

BLOCK TYPE STATEMENTS

-----------------------------------------------------------------------

TYPE BTFOO;

!BLOCKTYPE!

TYPEEXT BTEXTFOO;

!BLOCKTYPE, EXTENSION!

-----------------------------------------------------------------------

SOURCE PROGRAM INFORMATION

-----------------------------------------------------------------------

USE FOOUPROGRAM;

-----------------------------------------------------------------------

SYSTEM DEFINED PARAMETERS

-----------------------------------------------------------------------

NSYMB BCAPT = #8000;

!BLOCK PROPERTY SYMBOL FOR APT

!VALUE RANGE 0-65535

NSYMB BCTELDEV = #8400;

!BLOCK PROPERTY SYMBOL FOR

!TELEPHONY DEVICE

!VALUE RANGE 0-65535

NSYMB BCLOGDATA = #0400;

!BLOCK PROPERTY SYMBOL FOR VARIABLES

!IN THE DS DUMP, EXCHANGE DATA

!VALUE RANGE 0-65535

NSYMB BCEXTREC = #2000;

!BLOCK PROPERTY SYMBOL FOR EXTENSIBLE !

!FILES, SIZE ALTERATION

!VALUE RANGE 0-65535

NSYMB BTFOO = #8400;

!BLOCKTYPE FOR FOO = BCAPT (+) BCTELDEV!

!VALUE RANGE 0-65535

NSYMB BTEXTFOO = #2400;

!BLOCKTYPE, EXTENSION FOR

!FOO = BCLOGDATA (+) BCEXTREC

!VALUE RANGE 0-65535

CP-CP Unit Interaction

Looking at Figure 4.7, note the syntax and use of these Plex-C statements.

•

BLOCK

•

TYPE

•

TYPEEXT

•

USE

•

NSYMB

For a complete example of a Plex-C parameter list, fetch and study refer-
ence [11] using PItool or aps3 on the IBM.

Masking Block Types

For a given block type, how does the program check if the block type
includes a certain block characteristic? The answer is, the program masks
the relevant bits in the block type and compares the result with the block
characteristic. If the bits match, the check is successful. Relax, here is an
example.

Example 1

Assume the block type of the relevant block is in variable BLKTYPE.
Investigate whether the block has digital switching devices. Looking at the
relevant design rules, [7] to [10], the following holds:

•

Block characteristic symbol: BCDIGITAL, value: #8300

•

Block masking symbol: BMDIGITAL, value: #8700

Use the following code to determine the answer. Mind the binary AND
operator (*).

Figure 4.8

Masking block types

If BLKTYPE has the value #9302, is the check successful? The answer is
yes, because BLKTYPE (*) BMDIGITAL = #9302 (*) #8700 = #8300
which is equal to BCDIGITAL.

The same approach applies to block characteristics on AXE level in block
type extensions. The following example shows how to check two proper-
ties at one time.

IF BLKTYPE (*) BMDIGITAL = BCDIGITAL

THEN

! SUCCESSFUL, BLOCK HAS PROPERTY !

ELSE

! NEGATIVE, BLOCK DOES NOT HAVE PROPERTY!

FI;

Plex-C 2

Example 2

Assume variable BLKTYPEEXT contains the block type extension of the
relevant block. Investigate whether the block receives MML commands
and allows size alteration of a record file. Looking at the relevant design
rules, [7] to [10], the following holds:

•

Block characteristic symbol: BCCOMREC, value: #4000

•

Block masking symbol: BMCOMREC, value: #4000

•

Block characteristic symbol: BCEXTREC, value: #2000

•

Block masking symbol: BMEXTREC, value: #2000

Use the following code to determine the answer. Mind the binary AND
operator (*) and the binary OR operator (+).

Figure 4.9

Masking block types with two masking symbols

If BLKTYPE has the value #6200, is the check successful? The answer is
yes, because

•

BMCOMREC (+) BMEXTREC = #6000

•

BLKTYPE (*) (BMCOMREC (+) BMEXTREC) = #6200 (*) #6000 =
#6000

•

BCCOMREC (+) BCEXTREC = #6000

Left and right parts of the condition are equal.
Finally, consider this example based on code in APZ service block TRAN.

Example 3

Block TRAN receives command parameters with block names. TRAN
fetches the corresponding block number and checks the block type. TRAN
sends combined forward signal NOFORNAME to block LARI, and
receives block number and block type in combined backward signal
NOFORNAMEACK. If the block type includes the characteristics for
APT and telephony devices, TRAN sets variable TERROR to ZNO.

Examine the code in Figure 4.10. The code could use a few more com-
ments, they are missing due to lack of space.

IF BLKTYPEEXT (*) (BMCOMREC (+) BMEXTREC) =

BCCOMREC (+) BCEXTREC

THEN

! SUCCESSFUL, BLOCK HAS PROPERTY !

ELSE

! NEGATIVE, BLOCK DOES NOT HAVE PROPERTY!

FI;

CP-CP Unit Interaction

Figure 4.10

Receiving and analysing a block type

Function Codes

After some time, designers got tired of counting and masking bits. Support
engineers came up with a new and more convenient solution, function
codes.

SEND NOFORNAME WITH TRANPTR, CPARAMSTR,

WAIT FOR NOFORNAMEACK IN BLOCKTYPE200;

BLOCKTYPE200)

RETRIEVE NOFORNAMEACK WITH

TRANPTR,

TBLOCKNUMBER,

TBLOCKTYPE,

TBLOCKTYPEEXT;

IF TBLOCKTYPE (*)

(BMAPT (+) BMTELDEV) =

(BCAPT (+) BCTELDEV) THEN

! SUCCESSFUL, BLOCK HAS PROPERTY !

TERROR = ZNO;

ELSE

! NEGATIVE, BLOCK DOES NOT HAVE PROPERTY!

...

FI;

Plex-C 2

Figure 4.11

Function codes

Today, two design rules are relevant for function codes. Reference [3]
gives general information about how to define and apply function codes.
The document also lists all signals administering function codes. At the
end of the document, the text points out that function codes supplement
block types and block type extensions. Block types will not disappear, and
checking block types is still relevant today. However, AXE system steering
does not permit new block characteristics. Consequently, system designers
may only identify new properties for blocks using new function codes.

Reference [2] lists all available function codes. The document appears
with fresh updates at regular intervals. Today, in April 1997, the document
lists approximately 330 different function codes. At the end of the list, a
brief section explains how to order new function codes via Memo.
Examine this example of reference [2] in Figure 4.12.

Figure 4.12

Function code FCMANBLOC

• Definition: A function code corresponds to a defined signal volume

that belongs to a certain function.

• If a block has a function code, it must have the functionality corre-

sponding to the function code. It also needs to receive and send the
signals associated with the function.

• Blocks store their function codes at start/restart in block LARI

using signal pair STOREFUCODE/STOREFUCODEACK

• Programs interested whether a block has a particular function code

and receives the corresponding signals use signal pair
CHKFUCODE/CHKFUCODEACK to/from block LARI

FCMANBLOC

Application

Device blocks that can permit manual blocking of their

devices.

Signal set

SMBLOC/SMBLOCR

SMDBLOC/SMDBLOCR

RINDNUM/RINDNUMR

Reference

FS 71/155 17-APT 210 06

CP-CP Unit Interaction

Device blocks have function code FCMANBLOC, if their devices permit
manual blocking by the exchange technician. All blocks using the code
define FCMANBLOC as a global number symbol with value 56. Here are
typical declarations for FCMANBLOC.

•

SPI, declare sector: GLOBAL NSYMB FCMANBLOC (65535);

•

SPL/PL, system defined parameters: NSYMB FCMANBLOC = 56;

The function code corresponds to three pairs of signals. Blocks with
FCMANBLOC have to receive signals SMBLOC, SMDBLOC and RIND-
NUM and send signals SMBLOCR, SMDBLOCR and RINDNUMR.

Further information on the application of the function code is available in
the function specification document 71/155 17 APT 210 06.

Linking of Records

Building up a call, SW units communicate with a large number of signals.
The SW units handle several call attempts at the same time and assign one
record to each call attempt, subscriber line or telephony device. The SW
units link their various records by exchanging and storing each other’s
block reference and record numbers.

Figure 4.13

Linking records in SW units A and B

In the restart subprogram, blocks A and B send each other signals with
their own block reference. Each block stores the partner’s block reference
in a common stored variable.

At the beginning of a call set-up, blocks A and B send each other signals
with the numbers of their records assigned to the task. One record in block

RECORDA

BPOINTER

BBLOCKREF

Block A

RECORDB

APOINTER

ABLOCKREF

Block B

Plex-C 2

A interacts with one record in block B. The blocks store the record number
of the partner block in individual variables, BPOINTER and APOINTER
in Figure 4.13. After exchanging block references and cooperating record
numbers, the SW units can send multiple signals to each other.

Figure 4.14 shows some blocks participating in handling an outgoing call
in register position. Cooperating records in blocks KR2, LI2, and RE are
linked to a record in block CJ. In addition, the software links one RE to
one BT record.

Figure 4.14

Outgoing call in register position

In Figure 4.14, variable names such as CJIND are abbreviations for CJ
individual, or CJ record number or record pointer in block CJ. Variable
names such as CJBREF refer to the block reference of block CJ.

Optional Blocks in AXE

AXE exchanges use basic blocks, which are essential in all applications, as
well as optional blocks, which only some applications require. Before a
basic block sends a signal to an optional block, the basic block has to
ensure that the optional block exists. Otherwise the signal would have no
receiving statement.

Therefore, the optional block needs to inform all interested basic blocks
about its existence. This optional block sends this information as a signal

Record

CJIND

cjbref

CJBREF

Block KR2

Record

REIND

rebref

REBREF

Block BT

Record

CJIND

cjbref

CJBREF

Block LI2

Block CJ

Record

CJIND

btbref

BTBREF

Block RE

cjbref

CJBREF

BTIND

rebref

REBREF

Record

LI2IND

REIND

KR2IND

li2bref

LI2BREF

kr2bref

KR2BREF

CP-CP Unit Interaction

in the restart subprogram to those basic blocks that communicate with the
optional block. See Figure 4.15.

Figure 4.15

Interaction with optional AXE block

Please turn to reference [12] for further information about optional blocks.

Chapter Summary

Remember these points from this chapter.

Figure 4.16

Summary

Optional
AXE block

Restart subprogram

SEND

Traffic subprogram

ENTER

Basic
AXE block

Restart subprogram

ENTER

Traffic subprogram

SEND

SIGNAL1 WITH
OWN BLOCKREF

SIGNAL2

• Sending unique signals does not pose any problems.

• Sending multiple signals faces two difficulties: how to find the

reference of the receiving block? Does the receiving block
accept a certain signal?

• Block characteristics identify the properties of a block. They

are collected in block type and block type extension.

• Function codes describe the behaviour of a block and the asso-

ciated signals all block with this code have to handle.

• Declare block type, type extension, and function codes as glo-

bal number symbols in the SPI’s declare sector. Define their
values in the SPL/PL, section system-defined parameters.

• Masking allows to check block types for block characteristics.

• Dynamic linking between records refers to exchanging block

reference and record numbers between cooperating SW units.

• Optional AXE blocks contact their partner blocks at restart.

Plex-C 2

References

[1]

AXE 10 Survey
EN/LZT 101 1513 R2A
© Ericsson Telecom AB 1995

[2]

Function Codes in AXE 10 (DR)
ETX 102 60-1051 Uen
© Ericsson Utvecklings AB 1996

[3]

Function Codes (DR)
XT/UD 82 124
© Ericsson Telecom 1982

[4]

Plex-C Language Description
EN/LZB 101 1903 R2A
© Ericsson Telecom 1994

[5]

Software Reliability Handbook, Edition 4
EN/LZG 205 603
© Ericsson Telecom 1996

[6]

Plex-C 1 (course book)
especially Chapter 6, Block Interaction, and 7, Call Routines
EN/LZT 101 1279 R4B
© Ericsson Telecom 1996

[7]

Use of Block Types in AXE
X/UD 2523
© Ericsson Telecom 1980

[8]

Properties included in the Block Type Concept
1/X/UD 2523
© Ericsson Telecom 1984

[9]

Block Characteristics Structure
2/X/UD 2523
© Ericsson Telecom 1985

[10] Block Characteristics Symbols

3/X/UD 2523
© Ericsson Telecom 1984

[11] BLOSUPARAM, parameter list for BLOSU

190 73-CAA 107 4408 Rev. E
© Ericsson Expertise Ireland 1992

[12] Optional Function Blocks (DR)

ETX 102 60-1111 Uen
© Ericsson Telecom 1994

Chapter 5

Commands

Introduction

This chapter complements the module on input-output in Plex-C 1. The
chapter provides a deeper understanding of command syntax, COCA
number, translation routines and command parameter handling.

Figure 5.1

Chapter Objectives.

Input-Output Documents

The function designer creates four input-output documents during the
function specification process.

Figure 5.2

Input-output documents

Chapter Objectives

After completing this chapter, you are able to:

• Describe input-output documents

• Describe the syntax of MML commands

• Understand and define COCA numbers

• Write parameter handling routines

• Use service blocks for parameter translation

• Set error messages depending on IOCODE bits

Command
Description

Decimal class

n/190 82-CNT

COD

Printout
Description

Decimal class

n/190 83-CNT

POD

Operational
Instruction

Decimal class

n/154 31-CNT

OPI

Adaptation
Direction

Decimal class

n/155 42-CNT

ADI

Plex-C 2

COD. The command description shows the contents of a command and
its parameters in detail. This includes all possibilities and command vari-
ants, explanations and examples on how to use the command. The com-
mand description is important for testers and exchange technicians who
need to set exchange-dependent parameters in the right way. See reference
[1].

Example

In mobile telephony, a command description presents command MGBOI,
which defines a route from a mobile switching centre to a base station con-
troller.

POD. The printout description shows the contents, syntax and error mes-
sages of a printout in detail. Each printout needs its own printout descrip-
tion. However, several commands may share the same printout. See
reference [2].

Example

In the operation and maintenance subsystem, a printout description
presents the parameter values of processor load supervision.

OPI. The operational instruction describes the steps of longer tasks in a
flowchart-like fashion. Many of these steps will be AXE commands. Each
task has its own OPI document. The operational instruction is important
for testers and exchange technicians, because it explains in which order to
issue the various commands. See reference [3].

Example

In mobile telephony, an operational instruction presents the steps involved
in defining a cell.

ADI. The adaptation direction describes the commands available for set-
ting and changing exchange data. The ADI also discusses the important
command parameters and gives useful examples. Note that many AXE
commands, such as printouts and test commands, do not affect exchange
data, and do not appear in adaptation directions. See reference [4].

Example

An adaptation direction for subscriber data would describe all commands
defining and modifying these exchange-dependent parameters.

Commands

Command Syntax

Figure 5.3 presents typical cases of AXE commands. Note the use of spe-
cial characters in the command lines. See also reference [5] for more.

Figure 5.3

Sample AXE commands

➊

BLODI:DEV=BT3-10&-20;

Command BLODI allows manual blocking of specified telephony devices.
BLODI has only one command parameter, DEV. The parameter value,
here BT3-10&-20, follows the parameter name and the equals sign =. The
parameter value can include several parameter arguments, here two. The
AND operator &- indicates that this command blocks two devices, BT3-10
and BT3-20. These are also the parameter arguments.

➋

BLODI:DEV=BT3-10&&-20;

The UPTO operator && indicates that this command blocks 11 devices,
BT3-10 up to BT3-20. This command has 11 parameter arguments.

➌

BLODI:DEV=BT3-5&KR2-42;

Compare commands

➊

and

➌

. The latter uses the AND operator & to

combine devices from different blocks, BT3 and KR2. The parameter
value consists of two arguments, BT3-5 and KR2-42.

➍

DEV=LI2-128&&-255&RT-32&-33;

This line shows one command parameter only. The first parameter argu-
ment is LI2-128, and the total number of arguments is - guess - 130!

➎

PCORI:BLOCK=MCT2,IA=H’2A4:BLOCK=MCT1,IA=H’A4;

Command PCORI loads program corrections, also known as assembler
patches, into the program store at a specified instruction address (IA). The
example shows how to separate command parameters with comma (,),
here BLOCK and IA. Command PCORI also allows several parameter
blocks, which is very rare indeed. Separate parameter blocks with colon
(:). The command in the example loads two different corrections at two
start addresses.

➊

BLODI:DEV=BT3-10&-20;

➋

BLODI:DEV=BT3-10&&-20;

➌

BLODI:DEV=BT3-5&KR2-42;

➍

DEV=LI2-128&&-255&RT-32&-33;

➎

PCORI:BLOCK=MCT2,IA=H’2A4:BLOCK=MCT1,IA=H’A4;

➏

IOFII:FILE=file,VOL=vol/vol2/;

Plex-C 2

➏

IOFII:FILE=file,VOL=vol/vol2/;

Finally, command IOFII which defines input-output files. Parameter VOL
has two values, the new value vol and the check value vol2. Forward
slashes / separate new and check value. The check value is the old value
which the command overwrites with the new value now. For security rea-
sons, the operator has to specify the old value becoming obsolete. Do not
use check values in new design.

Time Gaps

Take a break and lose your pointers. Unfortunately, this sentence applies to
many input-output statements. These statements are really macros for
sending and receiving certain input-output signals. Figure 5.4 shows which
input-output statements rely on buffered and on direct, combined signals.
See also Chapter 15, Commands, in reference [7].

Figure 5.4

The truth behind input-output statements

All I/O statements include signal sending and EXIT statements, except
BUSY. Hence, programs lose values of temporary variables and pointers at
each I/O statement. It is important that designers make sure to save all data
needed again after the I/O statement. This is not necessary with the BUSY
statement, though.

Interference Problems

Input-output statements based on buffered signal sending require special
attention. The buffered signal is sent to job buffer level C and has to wait
until previous C-level jobs finish. During this time gap other signals may
affect the I/O-handling block. The designer has to make sure that such sig-
nals do not start any new I/O actions before the on-going I/O action termi-
nates.

Consider this example from reference [7].

BUFFERED SIGNAL
TIME GAP

COMBINED SIGNAL
NO TIME GAP

SEIZE DEVICE

RELEASE DEVICE
READ
WRITE

SEIZE DEVICE FOR

INSERT
FETCH
FETCH PARAMETER
FIND
CHECK

Commands

Figure 5.5

Signal interference in I/O-handling

Unit X receives a command and analyses its parameters. Unit X sends sig-
nal STARTJOB to start some activity in Unit Y. Before exiting, unit X
prints ORDERED using the INSERT TEXT and WRITE statements.
Later, when unit Y finishes its job, unix X generates a large result printout,
starting with seizing the I/O device.

If the job in unit Y finished quickly, unit X would receive signal
FINISHEDJOB before signal IOSVAL, confirming printout ORDERED.
When FINISHEDJOB enters unit X, the unit tries to seize the same I/O
device which is not released before signal IOSVAL arrives. The result is a
restart, FC 1601, initiated by the I/O system.

Job Buffer Level C

All I/O activities use buffer level C. However, the I/O statements using
combined signals cannot change to C-level. Therefore, it is the job of the
designer to ensure that the subprogram before the I/O statements FETCH,
FETCH PARAMETER, INSERT, FIND and CHECK runs on C-level.
Buffered signal CONTINUEC allows to continue the program execution
on the appropriate priority level.

PROGRAM

SIGNALS

Unit X

MCS/IOS

Unit Y

Unit X

Command analysis
finished

Command operation
results in starting job in
unit Y

INSERT TEXT ORDER,
ID IS CIOID,...

WRITE, ID IS CIOID,...
! Write “ORDERED”, using !
! WRT/IOSVAL signals

Job in unit Y finishes, receive
return signal

SEIZE DEVICE..., ID IS CIOID,...
! for large result printout !

STARTJOB

INSTXT

SIZAND1

IOSACKONE

WRT

FINISHEDJOB

Unit X waiting for signal IOSVAL

PROGERROR

System restart

Plex-C 2

Command Category Number

The input-output routines require three pieces of information from AXE
commands, see also reference [5].

•

check printout

•

command logging

•

authorization check

Check Printout. The command results in important changes in the
exchange which can be considered dangerous. For instance, command
SYREI restarts the exchange possibly losing calls.

The input-output routines automatically repeat commands with check
printout on the screen and require the user to confirm the command by
entering a semicolon (;). See Figure 5.6.

Figure 5.6

Confirming a command with check printout

Command Logging. The command changes RELOAD-marked variables
or EXCHANGE DATA. For instance, command SULII connects a new tel-
ephone subscriber to a line interface device.

The input-output routines save the command on the current command log
file. After a system reload with restart, the exchange can repeat the com-
mand from the file.

Authorization Check. Commands are ordered in functional groups.
Exchange technicians receive authorization to perform commands of cer-

syrei:rank=large;

SYREI:RANK=LARGE;

INHIBITED

syrei:rank=large;

SYREI:RANK=LARGE;

CONNECTION INTERRUPTED

TRX-A:5

AT-5

SYSTEM RESTARTED

RANK

LARGE

Commands

tain functions only. For instance, only few technicians may change charg-
ing data while all users have the permission to use printout commands.

Contents of COCA numbers

Check printout, command logging and authorization check depend on the
bits in the command’s COCA numbers. Please study Figure 5.7.

Figure 5.7

Format of COCA numbers

Bit 15 = 1. Activates check printout, the exchange technician needs to
confirm the command with a semicolon.

Bit 14 = 1. Activates command logging, the input-output routines save a
copy of the command on the current command log file.

Bits 13 and 12. These bits are always 0 (zero).

Bits 11 to 8. These bits are always 0 (zero) in classic AXE software. The
command level is relevant in application modularity software only. In
application modularity (AM) programs, several units may handle the same
command. The input-output routines need to keep track of which unit exe-
cutes the command. The command level identifies the priority level of the
command in AM software. Please study reference [12], when implement-
ing COCA numbers in AM units.

Bits 7 to 0. The eight lowest bits of the command category number iden-
tify the command category group. However, the input-output routines use
bits 5 to 0 only. See reference [9].

The command category group determines the permission to use a com-
mand. Access to most commands is limited. The list in reference [9] shows
the current command groups and their numeric values. Table 5.1 shows
some examples from this list. Printout commands use COCA group 0 and
are accessible to all users.

The unit or block designer does not have to determine the COCA number.
The function designer usually specifies the necessary input in the com-

15 14

cmd level

command category group

0 0

cmd logging

check printout

Plex-C 2

mand description document. Look for the sections Check Printout, Log-
ging and Command Category Group in the COD.

Table 5.1

Some command category groups in AXE

COCA Number in Command Receiving SW unit

Please study Figure 5.8 which shows how to declare and use the COCA
number for TCS command ANBSI.

Figure 5.8

Typical Plex-C code for COCA numbers

In Figure 5.8, the command category number COCA022 is reserved for
command ANBSI. The SPI declares COCA022 as a global number sym-
bol. The command reception statement in the SPI is the only place in the
program sector where the COCA number appears. The SPL or PL set the
value of COCA022 to hexadecimal 4021. This value indicates that the
command sets (B-number) analysis data and uses logging, but no check
printout.

When the input-output routines receive an MML command, they search all
command-receiving SW units for a matching COMMAND statement.
When successful, the input-output routines read the COCA number from

Dec.

Hex.

Function

Printouts

Authorization code administration II (dangerous commands)

Analysis data

Blocking route and other groups of devices APT

Blocking devices APT

Charging

SPI, Declare Sector

GLOBAL NSYMB COCA022 (65535);

SPI, Program Sector

COMMAND ANBSI TYPE COCA022,

ID IS TIOID, DEVICE IS CDEVTEMP, SOURCE IS TSOURCE;

SPL/PL, Application-dependent Parameters

NSYMB COCA022 = #4021;

!CATEGORY FOR COMMAND “ANBSI”!

!GUIDING VALUE = #4021

!VALUE RANGE 0 - 65535

Commands

the command-receiving SW unit. The number then tells the input-output
routines how to administer the command regarding check printout, logging
and authorization.

Command Parameters and IOCODE

When an exchange technician has entered a command, the input-output
routines check that the command spelling is correct. For instance, com-
mands need to end with a semicolon and parameter arguments have to be
separated by ampersand & or dash -. The I/O-system finds obvious flaws
relevant for all commands. For instance, the following command never
reaches a command-receiving SW unit.

BLODI12345;

However, only the command receiving block can check the details of com-
mand parameters and arguments.

FETCH PARAMETER

Two Plex-C statements make it possible to read command parameters into
the program, FETCH and FETCH PARAMETER. APT software, though,
does not normally use FETCH except to read in the semicolon for com-
mands without parameters such as

DPWSP;

printing the states of the cen-

tral processors. FETCH PARAMETER reads one parameter argument into
the SW unit and sets the IOCODE variable. The IOCODE is a 16 bit struc-
tured field variable which indicates status and errors after execution of the
FETCH PARAMETER statement.

Figure 5.9

Syntax of FETCH PARAMETER

Chapter 16.4, Summary, in the Plex-C Language Description, reference
[6], shows use and interpretation of the various bits in IOCODE. Each bit
may receive value 0 (not set) or 1 (set). If the bit is equal to 1, the FETCH
PARAMETER statement may or may not jump to the ABRANCH label.
FETCH PARAMETER does not touch some bits, namely bits 0 to 5, at all.

FETCH

PARAMETER

parameter name

value

NUM
STRING
ID
IDFCTR
NUMSTRING

1..

, ID IS

io-individual

, ABRANCH IS label

;

, POINTER IS pointer

, CODE IS io-code

Plex-C 2

Be careful, because these bits keep their values from the previous input-
output statement!

Please study Table 5.2 which summarises the meaning of the IOCODE bits
for FETCH PARAMETER. See also reference [6].

Table 5.2

FETCH PARAMETER: bits in IOCODE

Question

Study Table 5.2 and try to answer the following question: why does
FETCH PARAMETER include an automatic jump to the ABRANCH
label for bits 8, 9, A and B, but not for the other bits such as 6, 7, and E?

Bit

Value

ABRANCH

if value =

Official Text

Unofficial explanation

not changed

not relevant

IO device error

not relevant

Time out

EOT

Full seize queue

No device

Unknown seize code

0 or 1

All parameters not
fetched

More parameters in anal-

ysis buffer

0 or 1

All variables not
fetched

More parameter argu-

ments in analysis buffer

0 or 1

yes

Syntax error, not
correct type of ele-
ment

Format error

(see below)

0 or 1

yes

Exceeded value,
exceeded buffer

Unreasonable value of

argument

0 or 1

yes

Check value

Check value follows

0 or 1

yes

Parameter not found

Command lacks

expected parameter

Buffer to small

not relevant

Syntax error

not relevant

0 or 1

All parameter blocks
not fetched

More parameter blocks in

analysis buffer

not relevant

Commands

Syntax Error, Bit 8

The input-output routines set this bit in IOCODE variables for a number of
reasons. See Figure 5.10. F or more details, please read reference [13] and
[14].

Figure 5.10

Reasons for syntax error in IOCODE

Declaring the IOCODE

Figure 5.11 shows a typical declaration of an IOCODE variable using a
structure. Remember to use sensible names for the subvariables. See also
reference [7].

Figure 5.11

Typical declaration of IOCODE

Error Printouts

The man-machine communication subsystem, MCS, receives all AXE
commands and analyses their basic syntax. If the command follows the

•

Wrong data type in parameter argument.

•

Invalid separator in command. Only =, –, &, &&, &- and &&- are legal.

•

For Upto-repetition (&&): first value higher than second value.

•

Upto-repetition (&&) with STRING, ID or IDFCTR data type.

•

Parameter name appears twice in command.

•

Parameter does not end on comma, colon or semicolon.

•

Last parameter does not end on semicolon.

SPI, Declare Sector

!COMMON AND STORED VARIABLES!

VARIABLE CIOCODE DS;

!STRUCTURES!

STRUCTURE CIOCODE =

! BIT =

1 + 6,

! 0 - 5 NOT RELEVANT

1 MOREPARAMETERS 1,

! 6

MORE PARAMETERS IN CMD

1 MOREARGUMENTS 1,

! 7

MORE ARGUMENTS IN PARAM.!

1 SYNTAXERROR 1,

! 8

FORMAT ERROR

1 EXCEEDEDVALUE 1,

! 9

TOO LARGE/UNREASON VALUE!

1 CHECKVALUE 1,

! A

CHECK VALUE IN ARGUMENT !

1 PARAMETERUNKNOWN 1,

! B

PARAMETER NOT FOUND

1 + 2,

! C - D NOT RELEVANT

1 MOREPARAMETERBLOCK 1,! E

MORE PARAM. BLOCKS

IN CMD

1 + 1;

! F

NOT RELEVANT

Plex-C 2

basic syntactic rules, MCS searches through all command-receiving SW
units and this program continues with the processing of the command. The
following error printouts tell the operator that the command or parameters
were incorrect.

NOT ACCEPTED

The exchange rejects the command. No changes occur in the exchange.

PARTLY EXECUTED

The exchange executed the command for some parameter arguments, but
found a fault. The command does not process the remaining parameter
arguments.

SYNTAX ERROR

The man-machine communication subsystem, MCS, found a basic syntax
fault in the command and rejected it.

FORMAT ERROR

The command-receiving SW unit in APT found a syntax or format fault in
the command. Note that APT programs always use FORMAT ERROR, not
SYNTAX ERROR when finding syntax faults.

UNREASONABLE VALUE

One parameter argument was too large or invalid. The text applies if bit 9
in variable CIOCODE is set, or if the user program checks the parameter
argument on its own and finds it inappropriate.

Details

This text never appears on the terminal screen. Instead, the exchange dis-
plays the name of the faulty parameter and its value.

Study the typical examples in Figure 5.12 showing erroneous commands
and likely printouts. The string BLOCKFOO is too long to be a valid block
name.

Commands

Figure 5.12

Faulty commands and error printouts

Figure 5.13 provides an overview of conditions leading to Format Error
and Unreasonable Value. Please note that bits 6 and 7 do not necessarily
indicate a format error, their interpretation depends on the syntax of the
AXE command.

Figure 5.13

Format error and unreasonable value

Order of IOCODE Checks

Reference [13] requires to check the IOCODE bits in a certain order. In
general, check those IOCODE bits first which result in a jump to the
ABRANCH label. First test bit 8. Then bits 9, A, and B in any order.
Finally, test the other bits. The document states that, “If the bits are tested
in any other order, faulty bit values can be received.” Sounds frightening...

BLODI:DEV-BT3-6;

NOT ACCEPTED

FORMAT ERROR

BLODI:DEV=BLOCKFOO-10;

NOT ACCEPTED

UNREASONABLE VALUE

DEV=BLOCKFOO-10

DETAILS

BLODI:DEV=BT3-6&BLOCKFOO-10;

PARTLY EXECUTED

UNREASONABLE VALUE

DEV=BLOCKFOO-10

DETAILS

FORMAT ERROR

UNREASONABLE VALUE

Bit 6 More parameters than

Bit 9 Exceeded value, too large

allowed

Bit 7 More param. arguments

–

User program finds value

and repetition not allowed

too large or inappropriate

Bit 8 Syntax error

Bit A Check value in argument

Bit B Parameter not found

Bit E More parameter blocks

Plex-C 2

Please consider Figure 5.14 for a typical check of IOCODE bits. See also
reference [7].

The statement blocks FORMATERROR and UNREASVALUE print the
appropriate error messages and release the I/O device.

It is recommended to use the additional GOTO statement in Figure 5.14,
because it helps to reduce the number of checks.

The sample code assumes that the command has no further parameters,
and does not permit multiple arguments to parameter ROUTE.

Figure 5.14

Checking IOCODE bits in Plex

FETCH PARAMETER ROUTE

! FETCH ROUTE NAME

STRING TO CROUTE,

ID IS CIOID,

CODE IS CIOCODE,

ABRANCH IS FETCHROUTE110;

GOTO FETCHROUTE120;

FETCHROUTE110)

IF CIOCODE.SYNTAXERROR = 1 THEN

DO FORMATERROR;

! FAULTY COMMAND SYNTAX!

EXIT;

ELSIF CIOCODE.EXCEEDEVALUE = 1 THEN

DO UNREASVALUE;

! STRING TOO LONG

EXIT;

ELSE DO FORMATERROR;

! PARAMETER UNKNOWN OR !

EXIT;

! CHECK VALUE

FI;

FETCHROUTE120)

IF CIOCODE.MOREARGUMENTS = 1 THEN

DO FORMATERROR;

! REPETITION ILLEGAL

EXIT;

ELSIF CIOCODE.MOREPARAMETERBLOCK = 1 THEN

DO FORMATERROR;

! ONLY ONE BLOCK ALLOWD!

EXIT;

ELSIF CIOCODE.MOREPARAMETERS = 1 THEN

DO FORMATERROR;

! NO MORE PARAMETERS

EXIT;

FI;

! NOW CHECK IF CROUTE HAS REASONABLE ROUTE NAME !

Commands

Translation Functions

Many command parameters appear in a large number of commands. Here
are some typical examples.

•

subscriber number

•

device

•

device type

•

route

•

area code

To ensure a standardised treatment of these parameters, and to avoid
rewriting the same parameter fetching and printing subprograms again and
again, the service blocks TRAN and TRAN1 help with receiving and
printing these parameters. See reference [11] for complete information.

Example

Consider command

BLODI:DEV=BT3-42;

Rather than fetching parameter DEV itself, the user program sends a sig-
nal, namely INTDEV, to TRAN asking for assistance. The service block
fetches the parameter, checks if block BT3 exists, translates block name
BT3 into its block number, fetches the block type for BT3 and returns sig-
nal INTDEVR to the command-handling program. Please examine Figure
5.15.

Figure 5.15

TRAN fetches and translates parameter DEV

user

program

LARI

TRAN

IOS

Command BLODI

INTDEV

INTDEVR

Fetch Parameter DEV

NOFORNAME

NOFORNAMEACK

①

②

③

④

⑤

⑥

Plex-C 2

Command Reception for Multiple Users

Some commands are very popular. If several exchange technicians need to
issue the command in parallel, adapt the command-receiving SW unit for
multiple users. Adjust the data structure as in Figure 5.16. Assign variables
in one record to each command. Please see reference [10] for further infor-
mation.

Figure 5.16

Data structure for single- und multiple users

Chapter Summary

Remember these points from this chapter.

Figure 5.17

Summary

Single User Data

Multiple User Data

• CCOMMANDSTATE

• CIOID

• CDEVICE

• CSOURCE

• CCMDPARAMETER1

• CCMDPARAMETER2

• etc.

• COMMANDSTATE

• IOID

• DEVICE

• SOURCE

• CMDPARAMETER1

• CMDPARAMETER2

• etc.

• Essential syntax of AXE commands and parameters

• I/O statements destroy temporary variables, some include time

gaps

• Analysis of the IOCODE and error messages after FETCH

PARAMETER

• Service blocks TRAN and TRAN1 translate common com-

mand parameters for input or output

• Records allow to handle a command with multiple users

Commands

References

[1]

Command Description (Document Instruction)
2/1013-FCK 114 19 Uen
© Ericsson Telecom 1995

[2]

Printout Description (Document Instruction)
6/1013-FCK 114 19 Uen
© Ericsson Telecom 1995

[3]

Operational Instruction (Document Instruction)
5/1013-FCK 114 19 Uen
© Ericsson Telecom 1995

[4]

Adaptation Direction (Document Instruction)
1/1013-FCK 114 19 Uen
© Ericsson Telecom 1995

[5]

Command Format for AXE
TM/JE-91:455 Uen
© Ericsson Telecom 1993

[6]

Plex-C Language Description
EN/LZB 101 1903 R2A
© Ericsson Telecom 1994

[7]

Software Reliability Handbook, Edition 4
EN/LZG 205 603
© Ericsson Telecom 1996

[8]

Plex-C 1 (course book)
especially Chapter 6, Block Interaction, and 7, Call Routines
EN/LZT 101 1279 R4B
© Ericsson Telecom 1996

[9]

Function Groups and Command Category Groups in AXE (MAXE info)
TK/JE-89:097 Uen
© Ericsson Telecom 1996
Use DELTA library O&M, MAXE info, to find this document.

[10] Command Routines in AXE (DR)

ETX 102 60-1141 Uen
© Ericsson Telecom 1994

[11] Translation Routines for Command and Printout Parameters (DR)

LMI/86 B/548
© Ericsson Ireland 1987

[12] Modification of Command During Execution (DR)

ETX 102 60-1155 Uen
© Ericsson Telecom 1994

[13] Alphanumerical IO Functions for Plex Language (Interwork Description)

4/155 19-ANZ 218 01

Plex-C 2

[14] Format Errors versus Unreasonable Value (HAXE Memorandum)

ETX/TX/T-95:012 Uen
© Ericsson Telecom 1995
Use DELTA library O&M, MAXE info, to find this document.

Chapter 6

Printouts

Introduction

The operation and maintenance staff expects comprehensive, useful and
standardised information of an AXE exchange. This chapter introduces the
different types of printouts and how to program them.

Figure 6.1

Chapter Objectives

Printout Statements

Programming printouts is in general much simpler than writing code for
command receptions. There are two statements for alphanumeric input-
output in Plex-C:

•

INSERT

•

WRITE

INSERT places information in the I/O line buffer.

Figure 6.2

Syntax of INSERT

Chapter Objectives

After completing this chapter, you are able to:

• Describe the different types of printouts

• Write code for a result printout

INSERT

STRING

string

TEXT

textcode

TAB

position

, ID IS

io-individual

;

, POINTER IS pointer

HEX

VALUE

number

, FORMAT IS

num

Plex-C 2

Use INSERT STRING to place non-standard texts in the I/O line buffer.
The output string maybe any string not longer than 45 characters. The
combined signals behind INSERT cannot carry more signal data. The total
number of characters in the I/O line buffer may not exceed 72 characters.
The output string ought to be a global string symbol or a string variable
built up using global string symbols.

Whenever standard texts are available such as “END” or “NOT
ACCEPTED”, use INSERT TEXT. Note that INSERT TEXT expects a
local number symbol as textcode. See Standard Text Codes on page 94 for
a list of these number symbols.

Printing tables, use INSERT TAB to move the cursor to the next column.
INSERT TAB expects a global number symbol as input; that way it is pos-
sible to adapt column widths to the local language. Reserve sufficient
space for arguments in columns.

Be aware that all printouts are language-dependent. A single word in Eng-
lish may translate into several words in Spanish or French. Hence, allow
for sufficient space at all times.

Translation Functions

Service blocks TRAN and TRAN1 not only support fetching of popular
parameters, but also translating and inserting such parameters into the I/O
line buffer. See also Translation Functions on page 83. For full details,
please refer to reference [9].

Example

Consider a printout of device name

BT3-42

;

Rather than inserting the device name itself, the user program sends a sig-
nal, namely OUTDEV, to TRAN1 asking for assistance. Signal OUTDEV
carries the block reference of the device block as well as the device
number. The service block translates block reference into block name
BT3, and inserts the block name, the hyphen and the device number in the
I/O line buffer. TRAN1 sends signal OUTDEVR to the printout program.
Please examine Figure 6.3.

Note that TRAN1 only inserts text in the I/O line buffer, it does neither
insert tab-stops nor write the text to the I/O device. So, after sending signal
OUTDEV and receiving OUTDEVR, user programs need a WRITE state-
ment to output the text.

Printouts

Figure 6.3

TRAN1 translates and inserts parameter DEV

WRITE

The Plex-C statement WRITE sends the current contents of the I/O line
buffer to the I/O device or terminal. It also inserts line feeds and empty
lines in the printout.

Figure 6.4

Syntax of WRITE

WRITE BEFORE 2 NL outputs the text line followed by one empty line
and a line feed. WRITE without AFTER/BEFORE and WRITE BEFORE
1 NL have the same effect: they output the textline and a line feed. If no
new line is desired, indicate WRITE BEFORE 0 NL.

④

INSERT STRING/TEXT

⑥

③

⑤

②

①

user

program

LARI

TRAN1

IOS

OUTDEV

OUTDEVR

NAMEFORNO

NAMEFORNOACK

WRITE

WRITE

AFTER

BEFORE

, ID IS

io-individual

, CODE IS io-code

;

, ABRANCH IS label

, POINTER IS pointer

number

NEWPAGE

Plex-C 2

After executing WRITE BEFORE with NL > 0, the line buffer position
pointer points to the beginning of the new line.

Normally, user programs do not need WRITE AFTER n NL.

Example

Consider the example in Figure 6.5 showing a piece of Plex-C code and
the resulting printout. Take special notice of the number of line feeds and
empty lines shown. Each bullet symbol represents one line on the I/O
device.

Figure 6.5

Example for INSERT and WRITE

EOT

The exchange technician may interrupt longer printouts by pressing a
function key. In this case, the IOCODE of the WRITE statement sets bit 2.
The user program aborts the longer printout with the standard text shown
in bold print in Figure 6.6.

Figure 6.6

EOT: end of an interrupted printout

IOCODE in WRITE

Reference [6] describes the IOCODE bits for WRITE and other I/O state-
ments. Normally, it is not necessary to check the IOCODE bits in WRITE.

SPI, Program Sector

INSERT TEXT ORDER, ID IS CIOID;

WRITE BEFORE 3 NL, ID IS CIOID, ABRANCH IS LABEL990;

INSERT TEXT PREND, ID IS CIOID;

WRITE, ID IS CIOID, ABRANCH IS LABEL990;

Output on I/O Device

•

ORDERED

•

END

•

←

the next text appears here

EOT DURING PRINTOUT

text symbol EOTPRI (17)

END

text symbol PREND (12)

Printouts

Only longer printouts supporting EOT require user programs to check for
IOCODE bit 2.

Printout Types

AXE exchanges produce two major types of printouts.

•

command-initiated printouts

•

automatic printouts

Automatic printouts do not directly follow any AXE command. A typical
example for an automatic printout is an alarm printout (not discussed in
this chapter).

There are four different groups of command-initiated printouts. For more
details, refer to reference [1] please.

Check Printouts

The I/O system generates a check printout if the COCA number has bit 15
set. See section Check Printout on page 74 and onwards.

The check printout is an exact copy of the command written by the
exchange technician. The check printout appears directly after the original
command.

Procedure Printouts

These printouts follow immediately after the command and may only
include standard printouts. Figure 6.7 presents typical procedure printouts.

Figure 6.7

Standard texts for procedure printouts

Procedure printouts do not need a separate printout description. They are
mentioned in the command descriptions which also describe applicable
fault codes in detail.

Procedure printouts never terminate with END. During normal AXE oper-
ation, that is, while the CP load is not excessively high, the procedure
printout should begin 10 seconds after receiving the command at the latest.

•

EXECUTED

•

ORDERED

•

NOT ACCEPTED

•

PARTLY EXECUTED

•

UNREASONABLE VALUE (not allowed as first line)

•

FORMAT ERROR (not allowed as first line)

Plex-C 2

Answer Printouts

Answer printouts are longer, non-standard printouts that follow immedi-
ately after the execution of a command. Answer printouts need a separate
printout description document.

After receiving the command, the answer printout should start after 10 sec-
onds under normal traffic conditions. Otherwise printout the standard text
WAIT to indicate that the printout continues after some time.

When using answer printouts, the I/O device is not released. This means,
that the I/O device may be blocked for a long time and the exchange tech-
nician cannot give other commands while waiting. Therefore, it is usually
better to generate result printouts (see below) if longish code execution is
required.

Result Printouts

Result printouts are longer, non-standard printouts that follow the proce-
dure printout ORDERED, and a release and a seizure of the I/O device.
Result printouts require a separate printout description document and
always terminate with an END.

In order to seize the same I/O device again, it is necessary to save these
parameters of the COMMAND statement: I/O device name and I/O
source, the latter being the number of the remote data link if active. The
result printout is queued, if the I/O device is busy when seizing the I/O
device with SEIZE DEVICE.

Printouts

Summary

Please study Table 6.1 for an overview of command-initiated printout for-
mats.

Table 6.1

Command-initiated printout formats

Note that this table contains some simplifications and does not take dia-
logue-commands into account.

Printout Example

Command STDEP prints the states of telephony devices. Figure 6.8 shows
the beginning of such a printout. Please study the command and printout
descriptions for STDEP in Chapter 16, Command STDEP, at the end of
this book.

Figure 6.8

Sample printout after STDEP

Function

Check

Printout

Procedure

Printout

Answer

Printout

Result

Printout

Printout follows command immediately

yes

Printout must normally start 10s after
command reception

yes

Separate printout description required

yes

Terminates with END

yes

Release of I/O device after printout

yes

Procedure printout ORDERED precedes
printout

yes

Procedure printouts permitted before

yes

> STDEP:DEV=KR2-0&&-3;

DEVICE STATE DETAILS

DEV

STATE

BLS/FS

ADM

ABS

KR2-0

BLOC

MBL

H’01

KR2LSS

KR2-1

BLOC

MBL

H’01

KR2LSS

KR2-2

BLOC

TBL

H’01

LI3FOO

KR2-3

BLOC

MBL

H’01

BT2RSS

....

Plex-C 2

The example shows an answer printout. The printout has the name and the
heading DEVICE STATE DETAILS. Parameter DEV indicates the device
name, parameter STATE the device state, BLS/FS the blocking state, and
ADM the connection state. ABS indicates the numeric value of the global
device state. R indicates the name of the route a device is connected to.

Questions

Carefully study the printout in Figure 6.8 and try to answer the following
questions. The user program sends signal OUTDEV to insert the device
name and signal OUTRTE to insert the route name.

Table 6.2

Printout questions

Hints: one of the 7 questions has the answer 0 (zero). Adding all numbers,
the sum is 54

, the total number of all I/O constructs for this printout.

Standard Text Codes

The only official list of the standard text codes is part of the SPI of MCS
software unit AOTU. The list in Figure 6.9 bases on references [3], [4] and
[10]. Do not rely on other sources here, such as reference [7].

Figure 6.9 contains a complete list of standard texts for user programs.
Other symbols with numeric values between 40 and 55 are only relevant
for MCS software.

Standard text codes make translating printouts easier. That way, the string
ORDERED needs to be translated only once into Spanish or French,
namely in SW unit AOTU. Without standard text codes, the local customer
support had to translate ORDERED in hundreds of parameter lists of I/O-
handling SW units.

Question

Your Guess

How many WRITE statements are necessary to gen-
erate the printout?

How many INSERT TAB statements?

How many times does the program send OUTDEV?

How many times does the program send OUTRTE?

How many INSERT VALUE statements?

How many INSERT STRING statements?

How many INSERT TEXT statements?

1. Other results are possible, depending on the implementation.

Printouts

Figure 6.9

Number symbols for standard texts

Number Symbol Value

Text

DETAL

Repeats last parameter argument

ORDER

ORDERED

EXECU

EXECUTED

NOACC

NOT ACCEPTED

PAREX

PARTLY EXECUTED

INHIB

INHIBITED

COMUN

COMMAND UNKNOWN

COMRE

COMMAND RESTRICTED

COMBU

FUNCTION BUSY

FORME

FORMAT ERROR

UNRVA

UNREASONABLE VALUE

FACOD

FAULT CODE

PREND

END

BUFEX

BUFFER EXCEEDED

TIMEXC

TIME OUT

SYNFLT

SYNTAX FAULT

PBLNG

PARAMETER BLOCK TOO LONG

EOTPRI

EOT DURING PRINTOUT

NOEXC

NOT EXECUTED

FAUIN

FAULT INTERRUPT

DVERR

DEVICE ERROR

NOFIL

FILE NOT FOUND

EOTRQ

EOT REQUESTED

FULLQ

FULL DEVICE QUEUE

VOERR

VOLUME ERROR

FIERR

FILENAME ERROR

COERR

CODE ERROR

ILLOG

ILLOGICAL

CANCE

CANCELLED

SIERR

BLOCK SIZE ERROR

DAERR

DATA ERROR

TAEND

TAPE END

NETPE

NEXT TAPE PLEASE

BUFCO

BUFFER CONGESTION

WAIT

COMREDUMP

COMMAND RESTRICTED DURING

DUMP

NLOGBACKUP

*** NOT LOGGED FOR BACKUP

COMEX

COMMAND EXECUTED

COMNX

COMMAND NOT EXECUTED

FILER

FILE ERROR

MEEND

MEDIA END

Plex-C 2

Chapter Summary

Remember these points from this chapter.

Figure 6.10

Summary

References

[1]

Printout Format for AXE
TM/JE-91:456 Uen
© Ericsson Telecom 1993

[2]

Printout Description (Document Instruction)
6/1013-FCK 114 19 Uen
© Ericsson Telecom 1995

[3]

AOTU - Alphanumerical Output Transfer (Source Program Information)
190 55-CAAZ 107 1915
© Ericsson Telecom 1996

[4]

AOTU - Alphanumerical Output Transfer (Parameter List)
190 59-CAAZ 107 1915
© Ericsson Telecom 1996

[5]

Command Format for AXE
TM/JE-91:455 Uen
© Ericsson Telecom 1993

[6]

Plex-C Language Description
EN/LZB 101 1903 R2A
© Ericsson Telecom 1994

[7]

Software Reliability Handbook, Edition 4
EN/LZG 205 603
© Ericsson Telecom 1996

[8]

Plex-C 1 (course book)
especially Chapter 6, Block Interaction, and 7, Call Routines
EN/LZT 101 1279 R4B
© Ericsson Telecom 1996

[9]

Translation Routines for Command and Printout Parameters (DR)
LMI/86 B/548
© Ericsson Ireland 1987

• INSERT puts text into the line buffer, while WRITE transfers

text to the output terminal.

• Use INSERT TEXT and the default number symbols to pro-

duce standard texts.

• Command-initiated printouts consist of check, procedure,

answer and result printouts.

Printouts

[10] Alphanumerical IO Functions for Plex Language (Interwork Description)

4/155 19-ANZ 218 01
© Ericsson Telecom 1994
Use DELTA library O&M, MAXE info, to find this document.

Plex-C 2

Chapter 7

Software Recovery

Introduction

All the function blocks have start/restart subprograms. This chapter
describes how to write a simple start/restart program by using relevant
design rules.

Figure 7.1

Chapter Objectives

General

The terms start and restart, in the world of the designer, indicate which
parts of the software are activated.

After a system start, the software is able to handle APZ commands, and
can only react to operator commands.

After a system restart, the software is able to perform all normal activities.
A system restart restores the system to a predefined state. It is important
that a restart be fast and secure so as to maximize system availability and
performance.

For some software errors it is possible to suppress or delay the system
restart to a time when the traffic is low. That is called selective restart.

Through the introduction of forlopp, it is possible to concentrate the soft-
ware recovery to the process in which the fault occurred. Thus, a system
restart is not needed.

Appropriate design rules are listed at the end of this chapter.

Chapter Objectives

After completing this chapter and the related exercises, you will be
able to:

• Describe the system start and system restart processes

• Describe the system recovery actions

• Describe the forlopp concept

• Describe the system restart mechanism

• Write a start/restart program sequence

• Describe start of RP/EMRP

• Find the relevant design rules

Plex-C 2

100

Start/Restart after Initial Loading

The system is started after initial loading. The purpose of a start is to ena-
ble the APZ function blocks to receive and execute commands. Each func-
tion block has a state in the reference store (RS), which is set to

ACTIVE

when the block is started. The function blocks are started in a given
sequence. First the APZ blocks are started automatically (see 1 in Figure
7.2).

The MISSRA function block administers the start/restart process. It will
send the STTOR signal to the function blocks that have the block charac-
teristic BCAPZ. When the signal STTOR is received, the blocks execute
their start/restart program sequences on their own.

The APZ blocks enter a state in which they can only receive and execute
commands. The operator can now set the exchange clock, define RPs and
introduce program corrections, etc.

Most of the APT blocks are set to the

PASSIVE

state although some of

them, having certain block types, receive signals generated by APZ com-
mands (for functions such as size alteration and EM administration).

Next, APT is started by the command SYATI (see 2 in Figure 7.2). The
function block MISSRA sends the STTOR signal to the APT blocks,
which have the block characteristic BCAPT. Now the exchange is able to
handle all commands . The operators can, for instance, define telephone
devices, routes, and generate B-number analysis tables.

Figure 7.2

Start after Initial Loading

All exchange-dependent data can now be loaded by commands. This is
normally done from the exchange data file.

After initial load and start in the stand-by side (SB side) the CPs switch
sides, so that the SB side becomes the executive side (EX side). This is

APZ

APT

Start

CP-SB/SEP

CP-EX

SYATI;

Software Recovery

101

performed by executing the command DPSWI, which also generates a
large restart, see Figure 7.3. During the restart, the MISSRA block sends
STTOR to all function blocks. These will start traffic handling by inserting
periodic signals into the job table and time queues, and start hardware
scanning, etc.

Finally, the system is raised to parallel mode by executing the command
DPPAI, which will update and start the SB side. It changes state to SB/
WO.

A start must always be followed by a restart. A started system only per-
forms that what has been ordered by command. All the RELOAD declared
variables are defined in a restarted system. That is not the case in a started
system. See reference [1].

Figure 7.3

Restart after Initial Loading

APZ

APT

CP-EX

CP-SB/SEP

Large
Restart

DPSWI

Plex-C 2

102

System Recovery Actions

The program execution is continuously supervised by programs, micropro-
grams and supervisory circuits.

A system detected software error not leading to loops on THL, will gener-
ate a PROGERROR signal to the block JOB. JOB just passes the signal on
in the form of a SOFTWARE ERROR signal to the block MSWREC,
which coordinates the software recovery actions. The data sent with these
signals is assembled by the program/microprogram which detected the
fault and contains information about the error in the form of FAULTCODE
and ERROR INFORMATION words.

The recovery sequence starts in the block MSWREC which sends signals
to MISEDS and MISSRD with the purpose of saving data about the fault
situation. MISEDS is a general, processor-independent block, which owns
a number of variables in which fault code and error information are pre-
served. In addition to this the system attempts to preserve information
about the last jumps in the system before the fault was detected. It also pre-
serves the contents of the register memory (MALDATA), all dump marked
variables, and the job buffers.

All this information is stored in different hardware memories which are
implemented differently in APZ 211 and APZ 212. Block MISEDS there-
fore has to ask the processor-dependent block MISSRD (different versions
for different processors) for assistance. Block MISSRD allocates a DUMP
individual and sends a pointer to this back to MISEDS.

Figure 7.4

Preservation of Software Error Information

Error detected

MISEDS stores
fault code and
error information
in variables
FCODE and INFWORD

Signal

PROGERROR

from microprogram

Block

MSWREC

Block

MISEDS

Block

JOB

Software Recovery

103

Error data will always be saved during the recovery after detecting a
software error and irrespective of the type of recovery.

After the preservation, the MSWREC block has to decide on how to carry

out the recovery in each individual case. The recovery action should
disturb the traffic handling as little as possible, so immediate system
restarts are avoided if possible. The different steps in this process can be
illustrated by the flow chart in Figure 7.5.

Figure 7.5

SW Error Handling by MSWREC

If the error intensity is low, MSWREC first tries to establish if the error has
been detected during forlopp execution in which case normally a forlopp
release is initiated. To make this possible, the forlopp restart function must
have been activated by command.

ERROR

Forlopp release

System restart

Job in progress killed

Delayed restart

Immediate restart

Delayed reload

Yes

Forlopp release

possible and active?

Selective

Restart active?

Intensity

counter high?

Check block category

and error code

Next job started

System restart

Plex-C 2

104

If forlopp release is not possible but the selective restart function is active,
a recovery action is initiated depending on error type/code and block cate-
gory of the block where the error occurred.

Intensity Counter

If too many software errors have been reported within a short time, it can
be assumed that previous recovery attempts have caused severe errors in
the system. To be able to monitor the recovery intensity in the system, an
intensity counter is used. This counter is stepped each time an error lead-
ing to a recovery is detected. When a limit is reached, a restart is executed.
The limit can be set by command. Figure 7.6 shows the main principle.

Figure 7.6

Intensity Counter

The counter is increased with values specified in data for each error code.
The counter is decreased by one every hour. A command can be used to
change the limit, as well as set limits for different day categories (e.g.
lower limits during holidays). When a restart takes place in the system, the
counter is reset and starts from zero again.

Forlopp Release

Forlopp is a basic APZ function defined as events isolated from the rest of
the system. A Forlopp Release will only affect these events. However, the
forlopp function also requires adaptation of the APT software.

An event, e.g. a call, uses data records in different function blocks. These
data records are linked to each other, there is one chain of records for each
event or call. The main idea behind the forlopp function is to make these

Restart limit (default = 25)

+10

Counter value

-1 every hour

Time

Forlopp
release

Delayed
restart
Block cat. = 1

Delayed
restart
Block cat. = 0

Software Recovery

105

chains of records visible to the operating system. Then, the operating sys-
tem can release the chain of records (e.g. call) without affecting the other
chains.

In order to make these chains of records visible, the following steps are
necessary:

•

Each chain of records receives a unique identity, the forlopp identity
(FID).

•

A new APZ function, the forlopp manager (FM) keeps information
about the existing chains of records by storing block and record
number for all records participating in the same forlopp. The forlopp
manager is implemented by the block MFM.

•

Two new variables are introduced in forlopp-adapted APT blocks. The
variable CFLSTATUS indicates whether or not the forlopp function is
active, and FLCONNFID stores the forlopp identity, FID.

•

In addition, some changes affect the system restart sequence of a block
that has been adapted to forlopp. A forlopp-adapted block should at
least inform the APZ about its forlopp characteristics when sending
the system restart reply signal STTORRY. The signal description for
STTORRY indicates how to send forlopp characteristics, see Figure
7.22-Figure 7.27.

•

New procedures have been developed to simplify the adaptation of
existing blocks to forlopp. There are procedures for starting a new for-
lopp, introducing new individuals into an already existing forlopp, dis-
connecting an individual from a forlopp, releasing a forlopp, etc.

•

When sending signals between records in the same forlopp, the for-
lopp identity must be sent with the signal. Therefore a new register in
the register memory, the Forlopp Identity Register (FIR), is necessary.

Figure 7.7 shows the different parts required to implement the forlopp
function. See also reference [6] for the design rules.

Plex-C 2

106

Figure 7.7

Forlopp Implementation

The following is required to get a forlopp release in case of a software
error:

•

Low error intensity

•

The error is inside a forlopp

•

The forlopp handling and release function are activated

•

The error type allows a forlopp release

At a forlopp release, the FM sends signals for release to the blocks
involved according to the information stored in FM. The FM also writes
the contents of the records participating in the current forlopp in the soft-
ware error dump.

The forlopp concept includes standard functions for detecting hanging
calls, by means of forlopp time supervision. A forlopp can also be released
manually, by command.

The forlopp function provides a standardized function for application
detected errors (software irregularities). If a signal is received in the wrong
state, for instance, a standard procedure (FLERROR) is used to report the
application detected error.

Software
chains in
APT

Variable used
to store FID

FID = 3

FID = 2

FID = 1

Memory

FIR

Forlopp Manager

APZ

APT

Software Recovery

107

Selective Restart

If the error intensity function does not stipulate an immediate restart, and
forlopp release is not possible, the MSWREC block selects 1 out of 4
selective restart actions:

•

terminate execution of current job

•

delay system restart

•

immediate system restart

•

delay system reload

The recovery action depends on the following factors:

•

block category of the block which detected/had the error.

•

error type/error code

In order to determine how the system reacts on an error, the function
blocks of the system are classified in classes of importance. This means
that blocks handling central system information, like central APZ blocks,
have the highest category. Blocks writing in own, not system data, have the
lowest category. See Figure 7.8 for the different categories.

Figure 7.8

Block Categories

The block category is declared as a global number symbol,

BLOCAT

. Here

are some examples:

•

Block BUC (output functions) has block category 0.

•

Block KR2 (digit reception) has block category 1.

•

Block GS (group switch) has block category 2.

•

Block SAF (size alterations) has block category 3.

Category

Meaning and action

The block does not write in

RELOAD

marked varia-

bles and it does not take part in the traffic handling.

The block writes in

RELOAD

marked variables which

affect a limited number of individuals.The block par-
ticipates in the traffic handling but plays no important
role there.

The block writes in

RELOAD

marked variables which

affect many individuals or plays an important role in
the traffic handling.

The block writes in central system information.

Plex-C 2

108

In connection with start/restart, the blocks inform the APZ about their
block category when sending the signal STTORRY, see Figure 7.23. If the
block category is not sent in the signal, the APZ sets the default value 1.
For more information about block categories, see reference [3].

Every kind of software error in the system is assigned a unique error code.
The error code indicates the type of error and is used internally in the sys-
tem as well as outside the system (the code is printed in the restart print-
out). All error codes can be grouped into six main groups depending on
how the system handles the error situation. The Figure 7.9 gives a general
survey over the actions taken for these six groups:

Figure 7.9

Error Types

Error Type

Meaning and action

Error in identified RP: RP maintenance is informed
and takes actions.

Error in unidentified RP: A system restart is generated.

Error which can be located to one block:
- forlopp release if possible
- otherwise selective restart according to block category.

Error which require measures in the entire system:
Immediate or delayed restart/reload according to block category.

Error not requiring measures in the entire system:
The current process is killed.

Error during Function Change:
Same as for 1-5.CP sides are switched if there are more than three restarts
within 10 minutes

Software Recovery

109

System Restart

A system restart or reload can be initiated manually to clear error situa-
tions, for instance disconnection of a hanging device.

A manual restart is initiated by the following command:

SYREI:RANK=rank;

The value of

rank

could be

SMALL

LARGE

RELOAD

depending on

the type of system restart. The different types of system restart are
explained later in this chapter.

A system restart can also be initiated automatically as a recovery action
after a system detected software error. Here are some situations that lead to
an immediate system restart:

•

When the CP has lost contact with several RPs

•

Job buffer congestion

•

Program loops

If the result of the recovery analysis is an immediate system restart, this
restart is forced by executing a stop (XSTP) instruction in the block MIS-
SRD. This will lock the program execution in the microprogram for the
stop instruction and the only thing which can force the system out of this
stop loop is an interrupt signal on maintenance level, see Figure 7.10.

The AMU sends this interrupt signal as a response to a program handling
error (PHE) signal sent from the program handling check circuit (PHC) in
either CP side. PHC is an autonomous hardware counter incremented with
one during each primary interval. If the counter reaches the value 7, corre-
sponding to 70 ms, PHC sends the signal PHE to AMU .

Normally, a periodic job in block JOB resets the counter in each primary
interval. If the program execution is locked in a stop instruction or in a
program loop in a sequence executing at THL, block JOB cannot carry out
the periodic reset of PHC and PHC sends a PHE signal to AMU.

After reception of the PHE signal, the AMU will send the signal MIS to a
CP microprogram, MISR, which takes over the restart handling.

During the execution of this microprogram, the contents of all important
CP memories i.e. the jump address memory (JAM), the register memory
(RM), the job buffers and the contents of all DUMP marked variables are
be preserved in a protected area. Then the microprogram clears the CP
memories, except the protected part.

MISR determines the restart rank. The rank can be either small, large or
reload + large.

The microprogram terminates by sending signal SRSTT to the MISSRA
block, which takes control. First MISSRA resets all variables marked
CLEAR, and then MISSRA coordinates the restart of all functions by
sending the signal STTOR to all other blocks in the system. The signal
description for STTOR is shown in Figure 7.21.

Plex-C 2

110

Figure 7.10

The Restart Sequence

This part of the restart is divided into 255 absolute phases to ensure that
everything is started in a certain order. Each function block, however, par-
ticipates in a few phases only. To tell MISSRA about the phases a block
wants to participate in, all blocks have to send the relevant data to
MISSRA in phase 1 with the return signal STTORY. This signal also car-
ries information about block category and forlopp handling parameters.
See Figure 7.22 - Figure 7.27 for the complete signal descriptions.

Three levels of system restarts make it possible to minimize the distur-
bance on traffic handling. See Figure 7.11.

MISSRD

MISSRA

ISR

PHE

MIS

MISR

AMU

STTOR

STTORRY

STTOR

STTORRY

Execute

STOP instruction

PHC

USER
BLOCKS

Small, Large or Reload + Large

SRSTT

Preserve

Clear Job Table,

Job Buffers &
Time Queues

Error Data

Software Recovery

111

Figure 7.11

System restart levels

The first software error leading to a system restart causes a small restart. If
another serious fault occurs within a predefined time interval, t1, a large
system restart is initiated. In the event of a third serious fault within
another predefined time interval, t2, a reload and a large system restart take
place, representing the system's most extreme recovery action. The prede-
fined time intervals can be set by command, and they vary between 1-10
minutes, see Figure 7.12.

Figure 7.12

The Restart Escalation Window

• Small system restart, which does not affect calls in speech position,

and semipermanent connections. Other calls are disconnected. This is
a minimal system restart, which is performed without updating the
RPs and EMRPs.

• Large system restart in which all calls are disconnected. Semiperma-

nent connections are not affected.

• Reload and large system restart in which a reload is performed first to

ensure that RELOAD-marked variables contain correct values. This
is followed by a large system restart. Semipermanent connections are
disconnected and automatically re-established.

Time

Software

fault

Small

restart

Small

restart

Large

restart

Reload

Large

restart

>t1 min.

<t1 min.

<t2 min.

Plex-C 2

112

The Start/Restart Routine in a Function Block

General

There are limits on the time allowed for the performance of a system
restart, both on the total time and on the time per block.

It is important that part of the signal interfaces to the RP and EMRP be
speed-optimized. They may otherwise cause the CP to remain idle during
part of the system restart. In practice, RP and EMRP communication uses
more time than that indicated in measurements performed at test sites. The
reason is that real exchanges have more hardware installed than test sites.

During a system restart, it is also important to postpone all activities that
are not essential to the restart, to a point later in time.

Absolute Start Phases

The blocks must be restarted in a certain order. APZ is started first, so that
the APT blocks, when started, can utilize job administration. In the APT
block hierarchy, central functions such as those of the TCS blocks are
started first, followed by the blocks connected to the activities on the out-
going side. The CR blocks are started before the ITs, since these may need
to seize a CR when started. The slave is started before the master. Finally,
blocks connected to the incoming side are started.

The MISSRA divides block communication into 255 absolute phases.
However, fewer than 100 absolute phases include any function block activ-
ities. The phases are processed in increasing order.

Detailed rules describe the activities in each phase.

•

Phases 1-19 include the start/restart of APZ blocks, job management,
CP-RP communication, RP restart, etc. There are, however, a few
exceptions. The APT block NS (network synchronisation) is started,
and the BT block exchanges block references with other blocks.

•

Phases 20-49 cover the start/restart of APT blocks.

•

Phases 50-254 again cover APZ purposes, such as start of APZ routine
tests, and enabling of command execution. Only 22 of these phases
include an activity.

Symbolic Start Phases

The absolute start phases 20-49 are grouped into seven symbolic phases.
The symbolic phases are only used for descriptive reasons. Each block
performs an activity during a maximum of seven phases.

The symbolic phases, named SPH1-SPH7, are defined as local number
symbols in the PLEX program. The value of a symbolic phase is an abso-
lute phase. Unless there are special reasons, the symbolic phases will be
set to the first corresponding absolute phase, that is ZSPH1=20,

Software Recovery

113

ZSPH1=23, etc. to ZSPH7=38. APT blocks use the second absolute
phases (21, 24, 27,etc.) only in few cases, while the third absolute phases
(22, 25, 28,etc.) are very uncommon.

Table 7.1

Symbolic Start Phases

Table 7.1 shows the relationship between the absolute and the symbolic
start phases. Figure 7.13 shows the order in which the different symbolic
phases are carried out.

Figure 7.13

The Sequential Order of Start/Restart

Absolute Phase

Symbolic Phase

APZ

APT

1-19

20-22

SPH1

23-25

SPH2

26-28

SPH3

29-31

SPH4

32-34

SPH5

35-37

SPH6

38-49

SPH7

50-254

Job Management

CP-RP Communication

RP Restarts

SPH1

SPH2

SPH3

SPH4

SPH5

SPH6

SPH7

APZ

APT

time

. . .

APZ

19 20

49 50

Plex-C 2

114

Below follows a description of the activities performed in each symbolic
phase.

•

SPH1 (absolute phases 20-22):

−

Loading of an individual block reference by means of the

LOADREF

procedure.

•

SPH2 (absolute phases 23-25):

−

Loading of interaction information between blocks, for exam-
ple block references of other blocks.

•

SPH3 (absolute phases 26-28):

−

The primary job of SPH3 is call tracing at small restarts. Since
calls in speech position survive small restarts, it is essential to
verify that the important DS variables for such calls are still
valid. These DS variables include block references, record
numbers, STATE variables and other relevant data.

−

For calls that have been established by commands, so called
semipermanent connections, this check is done for both small
and large system restart.

−

The blocks CL, COF or SECA check that the records for tele-
phone devices taking part in a connection are correctly linked .
Figure 7.14 shows an example of such data links in speech
position, as well as the signals generated for call tracing during
a small system restart.

−

In Figure 7.14, the signal RSTRACE is first sent to the block
BT, with the BPOINT, CLREF and CLP. Block BT checks the
variables REF and POINT in its corresponding record. If they
agree with the signal data, the BT returns RSTRACED to the
CL block. The connection point in the group switch (GS) for
the BT device, stored in GSINL, is included in the
RSTRACED signal data. If a fault is found RSCLRD is
returned instead.

−

The CL checks the connection point with the help of the GS
block, and returns the GSINL with the signal RSTRACE. In
case of faults, the CL will send the RSCLEAR signal to the BT
block instead.

−

This sequence is then repeated between each block in the link.

Software Recovery

115

Figure 7.14

Call Tracing at Small System Restart

RSTRACE

REFERENCE BREF

WITH BPOINT

CLREF,CLP ...;

RSTRACED

REFERENCE REF

WITH POINT, GSINL...

RSTRACE...

WITH CLP, GSINL...

RSTRACED

WITH POINT,...

RSTRACE

WITH CLP

RSTRACED...

WITH POINT...

RSTRACE

REFERENCE IREF

WITH IPOINT, IREF, CLP...

RSTRACE

REFERENCE LIREF

WITH LIIND, LIREF, CJP...

RSTRACED

...

RSTRACED

REFERENCE TCSREF

WITH CJLINK,

WITH TCSIND,

CJLINK

LIIND

LIP

LIREF
LIREF

IPOINT

CJP

IREF

CJREF

REF

CLREF

POINT

CLP

TCSIND

CLP

TCSREF

CLREF

BPOINT

BTP

BREF

BTREF

GSINL

LIP

CJP

CLP

CIP

CLP

BTP

Plex-C 2

116

•

SPH4 (absolute phases 29-31):

−

Updating of states and blocking states (see page 118).

−

Generation of IDLE lists in device blocks.

−

Setting of start values in variables.

−

Updating of EM data.

•

SPH5 (absolute phases 32-34):

−

Updating of blocking directed to other blocks.

•

SPH6 (absolute phases 35-37):

−

Updating of remaining data.

−

All blocks have updated all data after absolute phase 37.

•

SPH7 (absolute phases 38-49):

−

SPH7 is only relevant for system restart and reloading with
large system restart, not for system start. Exception for phase
44.

−

In SPH7, the blocks activate themselves by storing their peri-
odic signals in job tables and time queues. Blocks containing
hardware also see to it that their regional programs start EM
scanning. However, traffic handling does not start until abso-
lute phase 44. Let's look at each absolute phase of SPH7:

Absolute phase 38:

−

Activation of central blocks necessary for traffic handling.
Central means that they do not receive line, register or sub-
scriber signals, for example the blocks JT, CJ, RT.

Absolute phase 39:

−

Activation of blocks that receive line, register or subscriber
signals although they are not yet able to receive a seizure or a
call signal, for example, CS, CR, OT, KR.

Absolute phase 40:

−

Activation of blocks that, for some reason, cannot start in
phase 38-39, but must be started before block LI.

Absolute phase 41:

−

Activation of LI and device blocks used for bidirectional traf-
fic.

Software Recovery

117

Absolute phase 42:

−

Activation of blocks of the incoming trunk type.

Absolute phase 43:

−

Activation of charging blocks and supervisory blocks, which
are not necessary for the call set-up.

Absolute phase 44:

−

This phase is relevant for all restart ranks.

−

Activation of blocks that do not participate in the traffic proc-
ess, such as command receiving blocks.

−

The #7 signalling links are activated. After this phase, all traf-
fic handling has started.

Absolute phases 45-47:

−

Activation of blocks that, for some reason, must be started
after phase 44. Phase 45 is selected first. If this does not work,
then phase 46 is selected, and so on.

Absolute phases 48-49:

−

Spares.

Plex-C 2

118

Variables STATE, BLSTATE and ADMSTATE

Each device block has the variables

STATE

BLSTATE

, and

ADMSTATE

defining the operating state of the device. See Figure 7.15.

Figure 7.15

Device Data Defining Operating States

•

STATE

indicates the global device state, such as idle, busy, blocked,

etc.

•

ADMSTATE

indicates how a device is connected. It is a structured var-

iable consisting of 4 or 8 bits. Modern design will use 8 bits.

The following bits may exist for

ADMSTATE

−

ADMSTATE.EMCON

: the device is connected to an extension

module, EM (0=connected)

−

ADMSTATE.GSCON

: the device is connected to the group

switch, GS (0=connected or never used)

−

ADMSTATE.SSCON

: the device is connected to the subscriber

switch, SS (0=connected or never used)

−

ADMSTATE.RCON

: the device is connected to a route (0=con-

nected or never used)

−

Bit 4 is equal to zero when the device is connected to other
units for example to the group switch.

−

Bit 5 is set when the device is in pre-post service. This means
that the device cannot be deblocked.

−

Bits 6 and 7 are never used.

STATE

ADMSTATE

RCON

SSCON

GSCON

EMCON

BLSTATE

BLO

BLT

BLM

MBL

Included in
each device
record of a
device block

Software Recovery

119

•

BLSTATE

describes the manner in which a device is blocked. It is a 4

bit structured variable. (bit=1 indicates blocked, bit =0 indicates
deblocked).

−

BLSTATE.MBL

: manually blocked

−

BLSTATE.BLM

: the EM controlling the device is blocked

−

BLSTATE.BLT

: blocked for tests

−

BLSTATE.BLO

: automatically blocked

The corresponding declarations can be seen in Figure 7.16, Figure 7.17
and Figure 7.18.

Figure 7.16

Declaration of Local Symbols

DECLARE;

! 2.2 LOCAL SYMBOLS !

NSYMB ZBLOC0=0; ! GLOBAL STATE BLOC !

NSYMB ZLIBL1=1; ! GLOBAL STATE LIBL !

NSYMB ZSEAL2=2; ! GLOBAL STATE SEAL !

NSYMB ZTEST3=3; ! GLOBAL STATE TEST !

NSYMB ZLOUT4=4; ! GLOBAL STATE LOUT !

NSYMB ZIDLE5=5; ! GLOBAL STATE IDLE !

NSYMB ZBUSY6=6; ! GLOBAL STATE BUSY !

NSYMB ZINOC7=7; ! GLOBAL STATE INCO !

NSYMB ZSEBU8=8; ! GLOBAL STATE SEBU !

...

NSYMB ZNO0=0;

NSYMB ZYES1=1;

NSYMB ZCOMPLCONNECTED0=0;

NSYMB ZDISCONNECTED1=1;

NSYMB ZNOTBLOCKED0=0;

...

Plex-C 2

120

Figure 7.17

Declaration of record devicedata

Figure 7.18

Declaration of Structures

! 2.3 RECORDS !

RECORD DEVICEDATA;

VARIABLE STATE 4 DS; !GLOBAL DEVICE STATE !

VARIABLE ADMSTATE 8 DS RELOAD; !CONNECTION STATE !

VARIABLE BLSTATE 4 DS; !BLOCKING STATE!

...

END RECORD;

POINTER DEVICEP (DEVICEDATA);

...

! 2.6 STRUCTURES !

STRUCTURE ADMSTATE =

1 EMCON 1, !0 EM CONNECTED!

1 GSCON 1, !0 GS CONNECTED!

1 SSCON 1, !0 SS CONNECTED!

1 RCON 1, !0 ROUTE CONNECTED!

1 + 4;

STRUCTURE BLSTATE =

1 MBL 1, !1 MANUALLY BLOCKED!

1 BLM 1, !1 EM BLOCKED!

1 BLT 1, !1 TESTBLOCKED!

1 BLO 1; !1 AUTOMATICALLY BLOCKED!

...

END DECLARE;

Software Recovery

121

The design rule in reference [1] describes how to update the variables

STATE

ADMSTATE

and

BLSTATE

. The following rules apply. Compare

with Figure 7.19.

•

At initial start, set all records to state

ZBLOC0

in symbolic phase 3.

•

At small and large restart, switch off automatic and test blocking in
symbolic phase 4. Set all records to

ZIDLE5

for devices not manually

blocked and not involved in a call in speech position.

•

At reload with large restart, set all records to state

ZBLOC0

in sym-

bolic phase 3. Later, in symbolic phase 4, set all records to state

ZIDLE5

for devices not manually blocked.

Figure 7.19

Updating of STATE, ADMSTATE and BLSTATE

STATE

ADMSTATE

BLSTATE

Global

state

route

subscr.

group

ex.mod.

BLO

autom.

BLT

test

BLM

MBL

manual

START
(SPH3)

SMALL

(SPH4)

RELOAD

(SPH3)

RELOAD

(SPH4)

ZBLOC0

YES

then

else

then

else

then

else

YES

ZIDLE5

ZBLOC0

ZIDLE5

YES

then

LARGE

Plex-C 2

122

The corresponding code in PLEX:

•

Phase SPH3:

−

start or reload with large system restart.

STATE=ZBLOC0

!block the device!

BLSTATE.BLT=ZNO0

!no test blocking!

BLSTATE.BLO=ZNO0

!no automatic blocking!

IF ADMSTATE=ZCOMPLCONNECTED0 THEN
BLSTATE.MBL=ZNO0

if connected no manual blocking!

ELSE
BLSTATE.MBL=ZYES1

!else manual blocking!

IF ADMSTATE.EMCON=ZDISCONNECTED1 THEN
BLSTATE.BLM=ZYES1

!EM connection missing ->!

!EM blocking!

•

Phase SPH4:

−

reloading with large system restart.

IF BLSTATE=ZNOTBLOCKED0

!no blocking at all!

THEN
STATE=ZIDLE5

!device is now available!

−

small and large system restart.

BLSTATE.BLT=ZNO0

!switch off test and!

BLSTATE.BLO=ZNO0

!automatic blocking!

−

For devices that are not connected to a call that is to be saved:

IF BLSTATE=ZNOTBLOCKED0

!if device not blocked!

THEN
STATE=ZIDLE5

!device is now available!

ELSE
STATE=ZBLOC0

!else block device!

Start of RP/EMRP

The RP/EMRP data is updated in the symbolic phase SPH4. This applies
to all types of system restart. The central software sends signal UPDARP
to the regional software. One signal updates the data of one EM. A large
number of signals are therefore needed to update the data of one RP or
EMRP.

The signal buffer capacity in the CP, RP or EMRP is limited. Only one RP
updating block at a time is active. Thus control can be kept over the
number of signals in the system at a given time. See reference [4] and [5].

Software Recovery

123

Handling of Data

All variables are declared in accordance with the manner in which they are
handled during and after start/restart/reload.

Table 7.2 shows the principles of how different types of variables should
be treated after start/restart.

Table 7.2

Data security at start/restart

STTOR/STTORRY

The STTOR signal initiates the start/system restart sequence in each func-
tion block. Block MISSRA sends the signal to all active blocks in absolute
phase 1 and later phases. The following data is included in the signal
STTOR:

•

STARTCASE

: information as to whether this is a start, a small system

restart, a large system restart, or a reload with a large system restart.

•

STARTPHASE

: the number of the absolute start phase.

•

STARTTYPE

: information as to whether all blocks are to be started/

restarted (global restart), or whether the start/restart will only affect
the called block or a grouping of blocks (local restart). Certain blocks
or groups of blocks are 'locally startable' in the sense that their start/
restart will not affect the rest of the system. Such blocks or groups of
blocks can be added or deleted from an operating exchange without
any disturbance.

•

SIGNALKEY

: an internal number that is returned by the acknowledge-

ment signal STTORRY. The same number is used for one STTOR-
STTORRY pair. The number allows block MISSRA to keep track of
all outgoing and incoming signals.

Start

Small system

restart

Large system

restart

System

restart with

reloading

DS
DS DUMP
DS STATIC

Cannot
be
trusted

Cannot be trusted
Exception: When the variable
value is checked in system restart
routine (call tracing)

Cannot
be
trusted

DS RELOAD
DS RELOAD DUMP
DS RELOAD STATIC

Can be trusted

DS CLEAR
DS CLEAR DUMP

Can be trusted

Plex-C 2

124

The called block returns the signal STTORRY as an acknowledgement to
each STTOR. If STTORRY is not returned, there will be a new system
restart.

The following data is included in STTORRY:

•

SIGNALKEY:

same as for STTOR, internal number for block MIS-

SRA.

•

BLOCAT

: a global number symbol indicating the block category of the

function block, see reference [3], and page 107.

•

Each block performs actions in a few absolute start phases (usually
one to four phases). These phases are returned as data with STTORRY
to the MISSRA block, allowing MISSRA to send STTOR in the right
phase. However, each block must be able to receive STTOR in all
phases, since there are some variants of the old restart block, SR, that
generates the signal to all blocks in all phases.

Signalling Level

Signal STTOR queues in job buffer C. The CP SW unit receiving STTOR
should remain on C-level (BAL1) during the restart.

Why is it important to stay on C-level?

•

Some restart programs involve long execution times, especially when
updating RP and EMRP software.

•

The program handling check circuit (PHC) causes a restart, if a THL
job lasts longer than 70 ms.

•

APZ SW releases a C-level (BAL1) job, if the job lasts longer than
5 - 10 s.

The execution time on C-level, 5 - 10 s, is sufficient for all restart subpro-
grams.

There is, however, one exception. When updating RP or EMRP SW, some
CP SW units use a time supervision function which monitors that the RP
or EMRP returns acknowledgement signals within a specific time. When
this time elapses, the CP program receives a job-table signal (CLTIME0)
on THL1. In this case, the subprogram must immediately lower the prior-
ity level to BAL1 after receiving signal CLTIME0. Use the signal CON-
TINUEC without DELAY to return to level C. In other cases, when a
'forced' level change for some reason is necessary, return to the C level
immediately.

Software Recovery

125

The Start/Restart Routine in a PLEX Program

Figure 7.20 shows the form of a start/restart routine as it appears in a
block.

Figure 7.20

Flowchart for Start/Restart Routine

•

After the reception of the STTOR signal, the program checks

START-

PHASE

and

STARTCASE

to determine whether any action is neces-

sary. For blocks that are locally startable, the

STARTTYPE

is also

checked.

•

When having the correct

STARTPHASE

and

STARTCASE

, the pro-

gram runs the start/restart tasks in the relevant phases .

•

At the end of the sequence, the program returns the STTORRY signal .

The signal descriptions for STTOR and STTORRY are found in Figure
7.21-Figure 7.27.

Consider this simplified example to understand the start/restart routine.

MISSRA

User block

STTOR

Yes

Start/Restart
tasks

STTORRY

STTOR

Relevant
start case

Relevant
start phase

Reception of Start Signal

Yes

Plex-C 2

126

Example

The KR2 block receives digits in the form of tone signals from a push-but-
ton telephone. The KRC devices receives the digits.

During start/restart, the block is active during the phases SPH1, SPH3,
SPH4 and SPH7. SPH1 corresponds to absolute phase 20, SPH3 to abso-
lute phase 26, SPH4 to absolute phase 29 and SPH7 to absolute phase 39.
The phase numbers are declared as local number symbols, that is,

ZSPH1KR

ZSPH3KR

ZSPH4KR

and

ZSPH7KR

. These are the actions in

each phase:

•

SPH1: the unit retrieves the block reference by means of the

LOAD-

REF

procedure and stores the reference in common stored variabl

COWNREF

•

SPH3: the unit updates individual variable

BLSTATE

. See section

Variables STATE, BLSTATE and ADMSTATE on page 118.

•

SPH4: the unit sets start values in the individual variables

STATE

and

BLSTATE

according to the rules on page 20. Note: KRC devices

are only used during call setup, and thus they can be disconnected dur-
ing all types of restarts.

KR2U also updates the data in EMRP software unit KR2R. KR2U
sends signal UPDARPKR to KR2R. One signal is sent to each EMRP
that is not blocked. A maximum of 32 signals are allowed in a signal
sequence. If KR2U needs to send more signals, it inserts a time gap
between each group of 32 signals. The time gap is implemented by
storing periodic signal CLTIME0 in the job table.

Each UPDARPKR signal must be acknowledged by the UPDARP-
KRR signal from the RP software. The acknowledgement signals are
time-supervised, maximum delay is 100-200 ms. The time supervision
inserts signal CLTIME1 in a time queue. Figure 7.28 and Figure 7.29
show the signal documents for UPDARPKR and UPDARPKRR
respectively.

As a result of the UPDARPKR signal, the EMRP software starts scan-
ning the KRC devices.

KR2U inserts the signal CLTIME0 in the job table .

•

SPH7: the unit removes all calls waiting for KRC devices from all call
buffers, except at start. The calls in the buffers were placed there
before the system restart, when all KRC devices were busy.The clear-
ing of a call buffer is accomplished by resetting the bit variable

BUFFBUSY

, associated with the buffer in question.

Software Recovery

127

Figure 7.21

Signal STTOR

DOCUMENT STTOR;

SIGNAL STTOR;

! 723/155 14-APZ 210 !

!FUNCTION: STARTSIGNAL AT START AND RESTART!

TYPE 1 MULTIPLE CP-CP; !SINGLE SIGNAL!

!POSSIBLE RETURN SIGNAL: STTRT, STTORRY !

!COMMUNICATION: SENDER: SR

RECEIVER: ALL BLOCKS!

LEVEL C BUFFER;

DATA D1 4, ! RESTART CASE !

D2 8, ! PHASE !

D3 1, ! TYPE OF START/RESTART !

D4 8, ! NOT USED, ALWAYS = 1 !

D5 8, ! NOT USED, ALWAYS = 1 !

D6 4, ! SYSTEM RESTART RANK !

D7 16; ! SIGNAL KEY !

!DETAILED DATA DESCRIPTION:

D1 C0 RESTART CASE IS INDICATED AS FOLLOWS.

. 0=SMALL RESTART

. 1=LARGE RESTART

. 2=LARGE RESTART INCL. RELOAD

. 3=START

D2 H0 RESTART PHASE,VALUE 1-255

D3 B0 INDICATES TYPE OF START/RESTART

. 0=GLOBAL

. 1=LOCAL

D6 C0 SYSTEM RESTART RANK

. 0=SMALL

. 1=LARGE

. 2=PROCESSOR RELOAD

. 3=SYSTEM RELOAD WITHOUT RESETTING OF DS

4=SYSTEM RELOAD WITH RESETTING OF DS

. 5=PROCESSOR EXCLUTION

. 6=SYSTEM START

D7 SIGNAL KEY, RETURNED BY SIGNAL STTORRY

END SIGNAL;

Plex-C 2

128

Figure 7.22

Signal STTORRY part 1(6)

DOCUMENT STTORRY;

SIGNAL STTORRY;

! 724/15514-APZ 210 !

! FUNCTION: RETURN SIGNAL AT SYSTEM START AND RESTART !

TYPE 1 CP-CP; ! SINGLE SIGNAL !

! RETURN SIGNAL TO : STTOR !

! COMMUNICATION: SENDER: ALL

RECEIVER: MISSRA !

LEVEL C BUFFER;

DATA D1 16, ! SIGNAL KEY !

D2 16, ! BLOCK INFORMATION !

D3 16, ! SIGNAL VERSION NUMBER !

D4 16, ! WANTED START/RESTART PHASE !

D5 16, ! WANTED START/RESTART PHASE !

D6 16, ! WANTED START/RESTART PHASE !

D7 16, ! WANTED START/RESTART PHASE !

D8 16, ! WANTED START/RESTART PHASE !

D9 16, ! WANTED START/RESTART PHASE !

D10 16, ! WANTED START/RESTART PHASE !

D11 16, ! WANTED START/RESTART PHASE !

D12 16, ! WANTED START/RESTART PHASE !

D13 16, ! WANTED START/RESTART PHASE !

D14 16, ! WANTED START/RESTART PHASE !

D15 16, ! WANTED START/RESTART PHASE !

D16 16, ! WANTED START/RESTART PHASE !

D17 16, ! WANTED START/RESTART PHASE !

D18 16, ! WANTED START/RESTART PHASE !

D19 16, ! WANTED START/RESTART PHASE !

D20 16, ! WANTED START/RESTART PHASE !

D21 16, ! WANTED START/RESTART PHASE !

D22 16, ! WANTED START/RESTART PHASE !

D23 16, ! WANTED START/RESTART PHASE !

D24 16, ! WANTED START/RESTART PHASE !

D25 16; ! WANTED START/RESTART PHASE !

Software Recovery

129

Figure 7.23

Signal STTORRY part 2(6)

! DETAILED DATA DESCRIPTION:

D1: SIGNAL KEY RECEIVED WITH STTOR

D2: BLOCK INFORMATION (ONLY VALID IF D3 > 1)

B0 - B3 = NUMERAL FOR BLOCK CATEGORY

(USED TO DETERMINE RECOVERY ACTIONS AFTER A PROGRAM ERROR

IF A PROGRAM ERROR IS DETECTED IN THE BLOCK THAT HAS

RECEIVED STTOR).

A DESIGN RULE HOW TO SELECT A VALUE FOR THIS DATA

CAN BE FOUND IN RELEVANT 'SYSTEM DESIGN MANUAL'

(ETX 102 60-1099 UEN, BLOCK CATEGORIES IN AXE).

= 0 THE BLOCK HANDLES EXCLUSIVELY NON CRITICAL PROCESSING.

TERMINATION OF ANY PROCESSING IN SUCH A BLOCK WILL

NOT ADVERSELY AFFECT ANY OTHER PROCESS IN THE SYSTEM,

I.E. IT IS ACCEPTABLE THAT THE FUNCTION IN WHICH THE

BLOCK IS INVOLVED WILL HANG.

EXAMPLES ARE COMMAND HANDLING BLOCKS, AND BLOCKS THAT

HANDLE PRINTOUT FUNCTIONS.

= 1 THE BLOCK HANDLES CONCURRENT PROCESSES RELATING TO

AN IMPORTANT FUNCTION, THE FUNCTION MUST NOT HANG.

TERMINATION OF PROCESSING WILL NOT ADVERSELY AFFECT

ANY OTHER PROCESS IN THE SYSTEM NOR WILL IT AFFECT

THE PROCESSING OF THE OTHER CONCURRENT TASKS FOR

THE FUNCTION, I.E. IT IS ACCEPTABLE THAT THE

SUBPROCESS TO THE FUNCTION WILL HANG.

EXAMPLES ARE BLOCKS THAT WORK ON A TASK INDIVIDUAL

LEVEL. THIS CATEGORY IS TO BE THE DEFAULT CATEGORY,

IF A BLOCK DOES NOT NATURALLY FIT ANY OF THE OTHER

CATEGORY DESCRIPTIONS, THEN THIS CATEGORY IS TO BE

USED.

= 2 THE BLOCK IS CRITICAL TO MANY FUNCTIONS IN THE SYSTEM.

IF SUCH A BLOCK WAS TO HANG IT WOULD ADVERSELY AFFECT

THE PROCESSING OF MANY FUNCTIONS IN THE SYSTEM OR

POSSIBLY HALT ALL PROCESS EXECUTION, HENCE TERMINATION

OF PROCESSING IN SUCH A BLOCK MUST NOT OCCUR.

SUCH BLOCKS TYPICALLY DO NOT PROCESS AT TASK INDIVIDUAL

LEVEL, BUT AT BLOCK LEVEL. EXAMPLES ARE BLOCKS THAT

HANDLE LOAD REGULATION, CHARGING, AND SYSTEM RESTART.

Plex-C 2

130

Figure 7.24

Signal STTORRY part 3(6)

= 3 RESERVED FOR USE BY APZ ONLY. BLOCKS WHICH ARE

CRITICAL TO SYSTEM INTEGRITY I.E. WRITE IN CENTRAL

SYSTEM INFORMATION. TERMINATION OF PROCESSING WILL

NOT ADVERSELY AFFECT ANY OTHER PROCESS IN THE

SYSTEM NOR WILL IT AFFECT THE PROCESSING OF THE

OTHER CONCURRENT TASKS FOR THE FUNCTION I.E. IT IS

ACCEPTABLE THAT THE SUBPROCESS TO THE FUNCTION WILL

HANG, HOWEVER A RISK TO SYSTEM INTEGRITY (AND THE

POSSIBILITY OF EXCHANGE FAILURE) IS INTRODUCED.

B4 - B7 MUST BE 0.

B8 - B15 IS INFORMATION FOR FORLOPP MANAGEMENT.

A DESIGN RULE HOW TO SELECT A VALUE FOR THIS DATA

CAN BE FOUND IN RELEVANT 'SYSTEM DESIGN MANUAL'

(ETX 102 60-1044 UEN, ADAPTATION TO FORLOPP IN AXE).

B8 IS INFORMATION ABOUT FORLOPP ERROR REPORTING,

THIS BIT IS ALWAYS VALID

= 0 THE BLOCK DOES NOT INCLUDE PROCEDURE FLERROR

FOR REPORTING SOFTWARE IRREGULARITIES.

= 1 THE BLOCK DOES INCLUDE PROCEDURE FLERROR FOR

REPORTING SOFTWARE IRREGULARITIES.

B9 IS ONLY VALID IF B15 IS 1, AND B11 IS 1

= 0 THE FORLOPP EXECUTION CONTROL STATUS IS LOCKED OFF.

= 1 THE FORLOPP EXECUTION CONTROL STATUS IS LOCKED ON.

B10 IS ONLY VALID IF B15 IS 1 AND B14 IS 1

= 0 THE FORLOPP HANDLING STATUS IS LOCKED PASSIVE.

= 1 THE FORLOPP HANDLING STATUS IS LOCKED ACTIVE.

B11 IS ONLY VALID IF B15 IS 1

= 0 THE FORLOPP EXECUTION CONTROL FOR THE BLOCK

CAN BE CHANGED TO ON/OFF BY COMMAND SYFSC.

= 1 THE FORLOPP EXECUTION CONTROL FOR THE BLOCK

IS LOCKED WITH THE VALUE FROM B9.

B12 IS ALWAYS VALID

= 0 FOR FAULTS DETECTED BY APZ DURING FORLOPP

EXECUTION A FORLOPP RELEASE SHOULD BE MADE IF

FORLOPPRES IS SET TO ACTIVE BY COMMAND SYRAC.

= 1 FOR FAULTS DETECTED BY APZ DURING FORLOPP EXEC-

UTION A FORLOPP RELEASE SHOULD ALWAYS BE MADE.

B13 IS ONLY VALID IF B15 IS 1

= 0 VARIABLES FOR THE CONNECTED INDIVIDUAL(S) IN

THE BLOCK SHOULD NOT BE DUMPED AT SOFTWARE

RECOVERY.

= 1 VARIABLES FOR THE CONNECTED INDIVIDUAL(S) IN

THE BLOCK SHOULD BE DUMPED AT SOFTWARE RECOVERY.

Software Recovery

131

Figure 7.25

Signal STTORRY part 4(6)

B14 IS ONLY VALID IF B15 IS 1

= 0 THE FORLOPP HANDLING STATUS FOR THE BLOCK CAN

BE CHANGED TO ACTIVE/PASSIVE BY COMMAND SYFSC.

= 1 THE FORLOPP HANDLING STATUS FOR THE BLOCK IS

LOCKED WITH THE VALUE FROM B10.

B15 = 0 THE BLOCK DOES NOT INCLUDE FORLOPP HANDLING.

= 1 THE BLOCK DOES INCLUDE FORLOPP HANDLING. THE

BLOCK MUST ALSO INCLUDE THE FORLOPP PROCEDURE

FLADMINISTRATION.

D3: = 5 MEANS THIS VERSION OF THE SIGNAL.

= 4 NOT RECOMMENDED

(MEANS THAT D2, B8 - B10 IS NOT VALID).

= 3 NOT RECOMMENDED

(MEANS THAT D2, B11 - B12 IS NOT VALID).

= 2 NOT RECOMMENDED

(MEANS THAT D2, B13 - B15 MUST BE 0).

= 1 NOT RECOMMENDED

(MEANS THAT D2 IS NOT VALID).

= 0 NOT RECOMMENDED

(MEANS THAT D2 CONTAINS THE NEXT WANTED

START/RESTART PHASE, D4-D25 IS NOT VALID).

D4-D25:

WANTED ABSOLUTE START/RESTART PHASES, THE FIRST IN D4.

THE FIRST DATA AFTER THE LAST WANTED PHASE SHOULD

BE = 255, THE REST OF THE LIST IS NOT RELEVANT.

IF MORE THAN 22 PHASES ARE USED D4 SHOULD BE =0 (ALL

PHASES), THE REST OF THE LIST IS NOT RELEVANT.

IF A LIST OF WANTED PHASES ARE SENT, THE PHASES MUST

BE LISTED IN INCREASING NUMERICAL ORDER.

EXAMPLE: A LIST OF 3, 19, 26 IS CORRECT

BUT A LIST OF 3, 26, 19 IS NOT PERMITTED.

! MISCELLANEOUS INFORMATION:

NOTE THAT SIGNAL STTOR MAY BE RECEIVED IN ALL PHASES

EVEN IF D3-D25 INDICATE THAT ALL PHASES ARE NOT USED.

STTOR IS ALWAYS RECEIVED IN PHASE 1 IN ALL BLOCKS.

WANTED START/RESTART PHASES AND BLOCK INFORMATION MUST BE

SENT IN ALL STTORRY.

D2-D25 SENT IN STTORRY IS VALID INFORMATION FOR THE BLOCK

THAT RECEIVED STTOR, NOT FOR THE BLOCK THAT SENDS STTORRY.

THIS IS IMPORTANT IF ONE BLOCK RECEIVES STTOR AND THEN SENDS

A SIGNAL TO A SECOND BLOCK, AND IT IS THE SECOND BLOCK THAT

SENDS STTORRY.

Plex-C 2

132

Figure 7.26

Signal STTORRY part 5(6)

BELOW IS 4 EXAMPLES OF STTORRY:

EX.1 3 PHASES ARE USED AND THE BLOCK DOES NOT USE FORLOPP

MANAGEMENT OR FORLOPP ERROR REPORTING

FLINFO = H'0000 MEANS:

- THE BLOCK DOES NOT INCLUDE ANY FORLOPP PROCEDURES

THE BLOCK INFORMATION (TBLOCKINFO) SHOULD BE

BLOCAT (+) FLINFO.

SEND STTORRY WITH

CSIGNALKEY, SIGNAL KEY FROM STTOR

TBLOCKINFO, BLOCK INFORMATION

5, MUST BE=5

SPHASE1, FIRST PHASE TO USE (LOWEST VALUE)

SPHASE2, SECOND PHASE TO USE (HIGHER VALUE)

SPHASE3, THIRD PHASE TO USE (YET HIGHER VALUE)

255 NO MORE PHASES ARE USED

EX.2 ALL PHASES ARE USED (OR MORE THAN 22 PHASES) AND THE

BLOCK DOES NOT USE FORLOPP MANAGEMENT OR FORLOPP

ERROR REPORTING

FLINFO = H'0000 MEANS:

- THE BLOCK DOES NOT INCLUDE ANY FORLOPP PROCEDURES

THE BLOCK INFORMATION (TBLOCKINFO) SHOULD BE

BLOCAT (+) FLINFO.

SEND STTORRY WITH

CSIGNALKEY, SIGNAL KEY FROM STTOR

TBLOCKINFO, BLOCK INFORMATION

5, MUST BE=5

0 ALL PHASES ARE USED

EX.3 ONLY PHASE 1 IS USED AND THE BLOCK ONLY USES FORLOPP

ERROR REPORTING

FLINFO = H'0100 MEANS:

THE BLOCK DOES NOT INCLUDE ANY FORLOPP PROCEDURES OTHER

THAN FLERROR FOR REPORTING SOFTWARE IRREGULARITIES

THE BLOCK INFORMATION (TBLOCKINFO) SHOULD BE

BLOCAT (+) FLINFO.

SEND STTORRY WITH

CSIGNALKEY, SIGNAL KEY FROM STTOR

TBLOCKINFO, BLOCK INFORMATION

5, MUST BE=5

255 NO MORE PHASES ARE USED

Software Recovery

133

Figure 7.27

Signal STTORRY part 6(6)

EX.4 ONLY PHASE 1 IS USED AND THE BLOCK USES FORLOPP

MANAGEMENT AND FORLOPP ERROR REPORTING

FLINFO = H'A100 MEANS:

- THE BLOCK DOES INCLUDE FORLOPP PROCEDURE

FLERROR FOR FORLOPP ERROR REPORTING

- THE BLOCK DOES INCLUDE FORLOPP HANDLING.

- THE FORLOPP HANDLING STATUS FOR THE BLOCK CAN

BE CHANGED TO ACTIVE/PASSIVE BY COMMAND SYFSC.

- VARIABLES FOR THE CONNECTED INDIVIDUAL(S) IN

THE BLOCK SHOULD BE DUMPED AT SOFTWARE RECOVERY.

- FOR FAULTS DETECTED BY APZ DURING FORLOPP

EXECUTION A FORLOPP RELEASE SHOULD BE MADE

IF FORLOPPRES IS SET TO ACTIVE BY COMMAND SYRAC.

- THE FORLOPP EXECUTION CONTROL STATUS FOR THE

BLOCK CAN BE CHANGED TO ON/OFF BY COMMAND SYFSC.

THE BLOCK INFORMATION (TBLOCKINFO) SHOULD BE

BLOCAT (+) FLINFO.

SEND STTORRY WITH

CSIGNALKEY, SIGNAL KEY FROM STTOR

TBLOCKINFO, BLOCK INFORMATION

5, MUST BE=5

255 NO MORE PHASES ARE USED

END SIGNAL;

Plex-C 2

134

Figure 7.28

CP-RP Signal UPDARPKR

DOCUMENT UPDARPKR;

SIGNAL UPDARPKR;

! 6/15514-CNT 212 1640 !

! FUNCTION: UPDATE OF COMMON EM DATA IN RP AND HW !

TYPE 1 MULTIPLE CP-RP; ! SINGLE SIGNAL !

NUMBER IS 5;

! POSSIBLE RETURN SIGNAL: RPRESKR !

! COMMUNICATION: SENDER: KRD

RECEIVER: KRD !

LEVEL B BUFFER; ! RP-SIGNAL VIA JBR !

DATA D1 16, ! MIN POINTER FOR EM !

D2 8, ! SIGNAL SAMPLE INFORMATION FOR RECEIVER IN HW !

D3 8, ! SIGNAL LEVEL FOR APPROVAL “ “ “ “ !

D4 8; ! CHECK SUM (D2-D3 ADDED WITHOUT CARRY) !

! DETAILED DATA DESCRIPTION:

D2: 0 = MY-LAW

1 = A-LAW !

END SIGNAL;

*END;

ID UPDARPKR TYPE DOCUMENT;

CLA 6/15514;

NUM CNT 212 1640;

REV A;

DAT 91-04-15;

DES PPV/KS/KSD PEKA;

RES ETX/TT/SFE;

APP PPV/KS/KSD;

END ID;

Software Recovery

135

Figure 7.29

RP-CP Signal RPRESKR

DOCUMENT RPRESKR;

SIGNAL RPRESKR;

! 18/15514-CNT 212 1640 !

! FUNCTION: COMMON EM DATA IN RP AND HW UPDATED.

ALL DEVICES AND CORRESPONDING DATA RESETED. !

TYPE 1 MULTIPLE RP-CP; ! SINGLE SIGNAL !

NUMBER IS 5;

! RETURN SIGNAL TO: UPDARPKR !

! COMMUNICATION: SENDER: KRD

RECEIVER: KRD !

LEVEL C;

SIGNAL GROUP KRDRPSIG;

DATA D1 16, ! MIN POINTER FOR EM (SNT) !

D2 8, ! RESULT OF UPDATE SEQUENCE !

D3 8, ! MESSAGE FROM KRDD !

D4 8; ! NUM OF RECEIVED UPDATONE SIGNALS BETWEEN !

! RPUPDATONE8KR I.E. MAX VALUE = 7. !

! DETAILED DATA DESCRIPTION:

D2:0 UPDATE OK

B0=1 ERROR INDICATION

B1=1 MISSING SIGNAL FOR CADENCE UPDATE

B2=1 MISSING ACK OR CHECK SUM ERROR FROM KRDD

D3:04 UPDATE ACK

05 CHECK SUM ERROR !

END SIGNAL;

*END;

ID RPRESKR TYPE DOCUMENT;

CLA 18/15514;

NUM CNT 212 1640;

REV A;

DAT 91-04-15;

DES PPV/KS/KSD PEKA;

RES ETX/TT/SFE;

APP PPV/KS/KSD;

END ID;

Plex-C 2

136

Chapter Summary

Having read this chapter, remember the points in Figure 7.30 .

Figure 7.30

Chapter Summary

Chapter Summary

• After an initial load the APZ is started before the APT.

• A large restart must follow the start.

• A forlopp release will only affect the procedure where the sw error

was found, not the whole system.

• If the function selective restart is active, a restart can be suppressed

or delayed.

• A system restart can be initiated manually or automatically.

• A system restart can be small, large, or a reload followed by a large

restart.

• The block MISSRA sends the signal STTOR to all function blocks

at a restart, and receives STTORRY.

• To start/restart the blocks in the right sequence, absolute and sym-

bolic phases are used.

• Each block has a start/restart program sequence.

• The restart program sequence will execute on C-level.

• A number of design rules must be used when designing the start/

restart program sequence.

Software Recovery

137

References

[1]

System Start and Restart in AXE 10 (DR)
ETX 102 60-1114

[2]

Use of Variables ADMSTATE and BLSTATE (DR)
ETX 102 60-1029

[3]

Block Categories in AXE (DR)
ETX 102 60-1099

[4]

Updating RP/RPD during System Restart (DR)
ETX 102 60-1072

[5]

Updating EMRP/EMRPD during System Restart (DR)
ETX 102 60-1073

[6]

Adaptation to Forlopp in AXE (DR)
ETX 102 60-1044

[7]

Software Reliability Handbook
EN/LZG 205 603

[8]

System Characteristics Handbook
EN/LZB 101 1978 volumes 1 and 2

Plex-C 2

138

139

Chapter 8

Job Execution

Introduction

This chapter discusses the program administration in the APZ, the various
ways of delaying jobs, execution time limits, the C-level rule, phase divi-
sion, change of priority level, risks for variable interference and preventing
interrupts.

Figure 8.1

Chapter Objectives

Program Administration in APZ

The APZ handles many different types of tasks including the job of the
operating system. As on regular computers, the operating system supports
and controls the functions of the central processors in the AXE. The CP
operating system is mainly executed by microprograms.

The operating system administers jobs, and not blocks, units or programs.
Figure 8.2 defines the term job, relevant throughout the rest of this chapter.

Chapter Objectives

After completing this chapter, you are able to:

• Describe the priority levels, the job table, the job buffers, and the

time queues

• Describe different ways of delaying jobs

• Understand the need for execution time limits and C-level rule

• Describe and implement phase division

• Adapt the code execution to the appropriate job buffer level

• Detect situations with variable interference

• Describe different ways of preventing variable interference

• Prevent interrupts from higher execution levels

Plex-C 2

140

Figure 8.2

Definition of Job

Not all jobs in the exchange are equally important. Therefore, the APZ pri-
oritises the order in which jobs are executed. For example, if a fault occurs
during routine testing, the handling of the fault will have a higher priority
than the testing itself. The operating system interrupts the testing process
and starts a fault recovery program.

The operating system uses the following mechanisms to prioritise jobs.

Figure 8.3

Concepts in APZ Program Administration

There are five program priority levels. They are listed below in priority
order.

MFL.

Malfunction level

This is the program level for action to be taken in case of serious
hardware or software faults. MFL is the highest priority level and is
only used by APZ. No associated set of CP registers.

TRL.

Trace level

This is the program level for action connected to tracing variables
and signals in running programs at lower priority levels. Only used
by APZ.

THL.

Traffic handling level

Normal working level for programs handling telephone or data traf-

• A job is the code executed from reception of a buffered signal in a

block until return to the operating system (first EXIT executed).

• The I/O statement COMMAND begins a job too.

• A job can include processing in other blocks due to the sending of

non-buffered signals (combined or direct).

• A job may end in a different block than the one it started in.

• An interrupt system with several levels, also called

Priority System

• Register Memory (RM)

• A Job Table

• 4 Job Buffers (JBA-JBD)

• 4 Time Queues (TQA-TQD)

Job Execution

141

fic. THL is divided into three sublevels: THL1, THL2, and THL3.

BAL 1. Base level 1

This is the level for operation and maintenance functions such as
command handling and output of data to files.

BAL 2. Base level 2

This level is assigned to routine tasks and self-test programs. BAL 2
is the lowest priority level.

When an interrupt causes a low-priority job to be suspended in favour of a
higher-priority job, the data of the waiting job is not lost. Since separate
register sets are assigned to each priority level (TRL, THL, BAL 1 and
BAL 2), calculations of the interrupting job do not normally affect the cur-
rent data of the waiting job. Figure 8.4 shows the register sets of the central
processors.

The prime advantage of this concept is fast job changes in the processor.
The data of the interrupted job remains in the register memory and does
not need to be saved in the data store. When resuming the interrupted job,
the processor can continue immediately without loading any variables.

Figure 8.4

Four sets of CP register memory

PR0

PR1

SR0

SR1

DR0

DR1

DR2

DR23

AR0

AR1

AR2

AR3

WR0

WR1

WR2

|
|
|

WR29

|
|

TRL

THL

Plex-C 2

142

Apart from MFL and TRL, the traffic-handling level (THL) jobs have the
highest priority in the exchange. The THL is divided into three sublevels:
THL1, THL2, and THL3. Since these sublevels share the same set of CP
registers, a THL1 job cannot interrupt a THL2 or THL3 job. Figure 8.5
lists the different traffic-handling levels.

Note that signals from the job table never carry any data and cannot be put
into a job buffer.

The job table can hold up to 1,024 signals (APZ 211 11, APZ 212 20).

Figure 8.5

Traffic-Handling Levels

Job buffer level A for THL2 jobs is relatively small and reserved for spe-
cial types of jobs such as:

•

Preferred traffic, eg. calls to emergency numbers (112 in Europe, 911
in North America)

•

Call tracing (command CTRAI) and signal recording (command
SIREI)

•

When an RP detects a fault (for instance a parity error)

The base level is divided into base level 1 and 2. See Figure 8.6

for details.

THL1

Job Table Signals

Short periodic jobs
(time supervision)

THL2

THL3

Job Buffer Level A

Preferred data and
telephone traffic

Job Buffer Level B

Regular data and
telephone traffic

Job Execution

143

Figure 8.6

Traffic-Handling Levels

C-level jobs can interrupt D-level jobs, because each level has its own set
of CP registers. The C-level is used for all jobs started by an operator com-
mand.

To make sure all jobs waiting in the queues get hold of the central proces-
sors, the execution time per job is limited. See reference [1] for the latest
execution time limits. The design rule Selection of Signalling Level, refer-
ence [5], describes which job buffer level is adequate for a certain task.

Job Table

The job table is a small signal queue for short, periodic jobs. The job table
consists of two segments in the data store, one for the counters and the
other for block and signal numbers. The first word, a 16-bit counter, indi-
cates the starting point of the job. The other two data words, block number
and signal number, refer to the code to be executed.

Every primary interval, that is every 10 msec, the system decrements all
counters by one. When a counter reaches 0, the program sequence
addressed by the block number of the receiving block (BN-R) and global
signal number (GSN) is started. The maximum waiting time for a job in
the job table is approx. 10 minutes.

BAL1

BAL2

Job Buffer Level C

Input-Output
Commands

Job Buffer Level D

Routine self-tests
(APZ)

Printouts

Plex-C 2

144

Figure 8.7

Program execution from the job table

Note that job table signals never carry any data. See Chapter 10, Job Table
Signals, for details about sending and receiving job table signals.

Job Buffers

The job buffers differ greatly in size and the number of signals they can
store. See Table 8.1 for the latest details, reference [6].

Processor

APZ 211 11

APZ 212 20

Job Buffer

JBA

JBB

JBC

JBD

JBA

JBB

JBC

JBD

Size per job buffer

1024W

8192W

2048W

4096W

32kW

4096W

Average maximum
number of queued
signals

about
128

about
1024

about
256

about
512

about
4096

about
512

Table 8.1

CP Job Buffers: system limits

CIS

COUNTER

BN-R, GSN

job x

job y

job z

job x

job y

job z

New Counter Value

EXIT;

Job Table

job buffer

buffered signal

ENTER

the “real” w

etc.

Job Execution

145

In Table 8.1, the number of queued signals is an estimation only. It is
assumed that a signal needs 3 data words for type, format, block numbers
and global signal number. On top of that, 0 to 25 data words may be used.
In Table 8.1, an average of 5 data words is assumed giving 8W per signal.

Time Queues

Buffered signals on any level may be delayed further using one of the four
time queues TQA to TQD. Each time queue can store up to 512 signals
(APZ 211 11, APZ 212 20).

See Figure 8.8 for TQA, the absolute time queue. Every minute, this queue
compares month, day, hour, and minute of each queued signal. In the
example, the signal will be sent to JBB on April 12, at 6 o’clock in the
morning.

Figure 8.8

The absolute time queue (and sample job buffer B)

Use the absolute time queue for jobs starting at a specific time. Setting the
day number to zero lets the job repeat every day at the specified time. Set-
ting the month number to zero lets the job repeat every month at a particu-
lar time.

Time queues B, C and D are known as the relative time queues. Figure 8.9
shows some details.

1 Min.

Absolute Time Queue

TQA

Job Buffer JBB

Plex-C 2

146

Figure 8.9

The relative time queues (and sample job buffer JBB)

The system scans the relative time queues at intervals of 100 ms, 1 second
and 1 minute. A counter value of # FFFE in the 1-minute time queue
would delay the job to be executed by approx. 45 days.

Any buffered signals may be stored in a time queue. Follow this simplified
Plex-C syntax box to send a buffered signal using a time queue.

Figure 8.10

Sending a buffered signal with time delay (simplified)

Jobs and Execution Times

Time is a precious resource in telephony. Reference [1] describes a tele-
phone exchange as “a queuing system. Most of the jobs have to wait in
buffers before they are fetched by the central processor. To fulfil the cus-

Max 109 Min.

Max 19 H.

Max 45 Days

100 ms.

1 s

1 Min.

Relative Time Queues

# 0150

# FFFE
# 0032

|
|
|

TQD

TQC

TQB

Job Buffer JBB

numeral

field expression

DELAY

DELAY UNTIL

month, day, hour, minute

REFERENCE

field variable

SEND

signal name

signal datum

WITH

1..

field variable

;

Job Execution

147

tomer requirements on maximum acceptable delays, e.g. time to dial tone,
restrictions must be put on the execution times for all jobs, since job exe-
cution time and the loadability of the processor (upper load limit allowed
in the processor) are the variables that affect the delays.”

Time Limits

Tight execution time limits guarantee fast access to the CP for all jobs
depending on their job buffer level. According to reference [1] the follow-
ing values apply.

Table 8.2

Execution Time Limits

The execution time limits in the second table column apply to all proces-
sors. The number of executable statements, however, depends on the proc-
essor family. Table 8.2 shows the maximum number of ASA statements in
regular style and the number of Plex-C statements in bold type. For
instance, after receiving a JBC-level signal, a program should not execute
more than 4k=4000 ASA or 1500 Plex-C statements on APZ 211 11 sys-
tems.

The relationship between ASA and Plex-C statements is only an approxi-
mation. In reality, the number of ASA statements is relevant. Use Emu-
DumpGenTool to generate ASA code for an AXE program and PlexView
to browse the ASA version of Plex-C software.

If the software has to run on different processor families, the least power-
ful CP type determines the execution time limits. Usually the APZ 211 11
processor sets the standard.

Interrupt jobs which require too much CP time using phase division.

Priority

Time

Limit

APZ 211

APZ 212

Job table

0.1 ms

200

800

300

JBA, JBB

1 ms

800

300

2000

800

3000

JBC

5 ms

1500

10k

4000

40k

15k

JBD

50 ms

40k

15k

100k

40k

400k 150k

Plex-C 2

148

Figure 8.11

Definition of Phase Division

Buffer Congestion

Phase division also applies to programs needing to send a lot of signals in
one sequence. To avoid an overflow in the job buffers, the number of sig-
nals that a CP SW unit may send is restricted. See also reference [4]. This
design rule contains the following limits.

Figure 8.12

Limitations in Signal Sending

Phase Division: Implementation

Three signals implement phase division, CONTINUEB, CONTINUEC,
and CONTINUED. The last letter in their names indicates the job-buffer
level of the signals, B, C or D.

Figure 8.13 shows the signal description for CONTINUEB. Send up to 10
data words with the signal, each data word can have to up 16 bits or be R-
declared. CONTINUEC and CONTINUED have similar signal descrip-
tions.

To add additional execution time to other jobs waiting for the central proc-
essors, insert CONTINUEB/C/D in the time queue using the
SEND ... DELAY statement.

• Phase division means that a long sequence of code is split in parts

and executed as several jobs.

• Phase division typically occurs in loops over large record files.

• Send signals to the job buffer at each phase division, usually

CONTINUEB or CONTINUEC.

• Other jobs in the job buffer can start without having to wait for too

long.

• Do not send more than 32 buffered signals in one sequence.

• Otherwise insert phase division between each group of 32 signals.

• Sending several B-level signals, insert signals CONTINUEB or

CONTINUEC.

• Sending several C-level signals, insert signals CONTINUEC or

CONTINUED.

Job Execution

149

Figure 8.13

Signal description for CONTINUEB

Example

Consider the following example where a loop changes variable STATE to
BLOCKED in all idle records. The iteration starts at record number
CPREPNUM - 1 and ends at record number 0. Constant ZSCANMAX
contains the number of iterations after which phasing is necessary.

DOCUMENT CONTINUEB;

SIGNAL CONTINUEB; !FUNCTION: CONTINUATION OF WORK ON

B-LEVEL. THE SIGNAL IS USED TO

CHANGE THE PRESENT LEVEL OF A

PROGRAM TO B-LEVEL OR TO

DIVIDE A WORK ON B-LEVEL IN

DIFFERENT PHASES !

TYPE 1 MULTIPLE CP-CP;

! SINGLE SIGNAL !

!COMMUNICATION: SENDER ALL

RECEIVER ALL !

LEVEL B BUFFER;

DATA D1 T,

D2 T,

D3 T,

D4 T,

D5 T,

D6 T,

D7 T,

D8 T,

D9 T,

D10 T;

! THIS SIGNAL IS PREPARED TO TRANSFER VALUES > 64K !

END SIGNAL;

END DOCUMENT;

ID CONTINUEB TYPE DOCUMENT;

CLA 706/15514;

NUM APZ 210;

REV D;

DAT 91-11-08;

DES TX/ZBD EKU;

RES TX/ZBD;

APP TX/ZU;

END ID;

Plex-C 2

150

Figure 8.14

Sample flowchart for phase division

Figure 8.14 shows how to split the loop into sets of iterations. Each set of
iteration starts at pointer value TSCANSTART and ends at pointer value
TSCANSTOP. After each set of iterations, decrease TSCANSTART and
send signal CONTINUEB, unless TSCANSTOP is equal to 0 indicating
the end of the scanning process.

CONTINUEB
WITH TSCANSTART
[ THISBLOCK

TSCANSTART

< ZSCANMAX

TSCANSTOP = 0

FOR ALL RECORDS
FROM TSCANSTART UNTIL TSCANSTOP

STATE

IDLE

SET STATE BLOCKED

FOR ALL RECORDS
FROM TSCANSTART UNTIL TSCANSTOP

TSCANSTOP

/*TASK COMPLETE,
PROCEED */

OTHER

TSCANSTART = TSCANSTOP - 1

CONTINUEB
WITH TSCANSTART
[ THISBLOCK

OTHER

> ZSCANMAX

TSCANSTOP = TSCANSTART - ZSCANMAX + 1

/* BEGINNING OF TASK */

TSCANSTART = CPREPNUM - 1

Job Execution

151

C-Level Rule

Jobs on buffer level C are subject to additional restrictions. The C-level
rule describes these restrictions.

Figure 8.15

C-level rule

This is the reason for the 3% rule and the 5-second interval: the APZ con-
tains a load supervising function in block LOAS which limits the number
of incoming calls when the processor load is high. The processor load is
defined as the amount of time when the processor is working at levels
above the D-level. The processor load is measured in 5-second intervals.

If a job at C-level generates too much CP load during a 5-second interval,
there is a risk that LOAS rejects new incoming calls. This results in the
undesired effect that a low-priority function at C-level restricts the high-
priority traffic handling at B-level.

Figure 8.16

Load regulation function in LOAS

• A job on C-level may not increase the CP load by more than 3%.

• Implement a C-level task in several shorter jobs, because thirty

5 ms-jobs do not exhaust the processor load as much as one
150 ms job.

• These jobs together may not exceed 150 ms CP time during a

5-second interval.

START every 5 seconds

CP load
/* Percentage of jobs on C-level or higher */

OTHER

STOP

> 95%

LIMIT THE NUMBER OF
NEW CALLS IN THE NEXT
5 SECONDS INTERVAL

Plex-C 2

152

Implementation

Figure 8.17 shows two alternatives for a C-level job. The first solution
splits the job in several small segments. The second solution uses all 150
ms CP time at once, and then takes a longer pause. The design rule, refer-
ence [1], recommends the first solution, because it loads the CP in a more
even way. The second solution requires more checks to determine when to
create the time gap.

Figure 8.17

Splitting a C-level job

Send signal CONTINUEC with DELAY to meet the requirements of the
C-level rule.

Restart

Note that block LOAS does not supervise the C-level execution times at
restart. Hence, the C-level rule does not apply to start/restart subprograms.
Nevertheless, take all efforts to make start/restart subprograms as short as
possible.

Selection of Level

The level of the incoming buffered signal normally determines the priority
level of a job. However, in some cases the level of the incoming signals
does not match with the activity of the job. See also reference [5].

Example

Block A sends a B-level signal to command-handling block B asking for a
printout. Since all I/O-handling tasks have to execute on C-level, Block B
needs to change the priority level of the subprogram to C.

Level Change

The signal description defines the priority level of each signal. If the signal
begins a job which should use a different priority level, send signal CON-
TINUEB, CONTINUEC or CONTINUED to the current subprogram in
order to continue execution on the appropriate job buffer level. This proce-
dure is known as level change, see Figure 8.18.

150ms

5 seconds

Pause

Short frequent jobs

Job Execution

153

Figure 8.18

Example for level change

Variable Interference

Variable interference affects DS variables only. There is a whole range of
interference scenarios, some appear in this section. All interference situa-
tions share the fact that a job writing to a DS variable interrupts or disturbs
another job reading the DS variable in the same SW unit.

This section discusses four interference cases. For more information and
more examples, please refer to chapter 4.4 Interference in reference [2].

Interference Case 1

This is the classic interference situation. A job on B-level interrupts a run-
ning job on C-level sharing a DS variable. See Figure 8.19.

Signals SIGNALCLEVEL and SIGNALCLEVELR queue in job buffer
level C. Signals SIGNALBLEVEL and SIGNALBLEVELR queue in job
buffer level B.

In Figure 8.19, the C-level job sets CVAR to 42. If the B-level job inter-
rupts the on-going C-level process, CVAR changes to 6 interfering with
the job on level C.

ENTER BLEVELSIGNAL WITH

!Signal on B-level

DEVP;

!received

SEND CONTINUEC

!Level Change

REFERENCE COWNREF

!to C-level

WITH DEVP;

EXIT;

ENTER CONTINUEC WITH

!Continue after pause

DEVP;

!on C-level

!PROCEED WITH REGULAR JOB

Plex-C 2

154

Figure 8.19

Interference case 1

Interference Case 2

Combined signals are critical too. Here the current job buffer level may not
be obvious, since the actual job buffer level depends on the level of the job
sending the combined signal.

In Figure 8.20, a B-level and C-level job may send the combined signal. If
the combined signal uses DS variable CVAR for signal data, a B-level job
may interrupt the on-going execution on C-level. The effect is that the B-
level job overwrites the value of CVAR and thus disturbs the C-level job.
Avoid this problem by always using temporary variables for jobs started
by combined signals.

Job Execution

155

Figure 8.20

Interference case 2

Interference case 3

In this case, the job stores the combined signal in temporary TVAR as rec-
ommended. The job returns TVAR with backward signal COMBINED-
SIGNALACK. However, in the middle of the flow, the job looses the value
of TVAR due to sending combined signal COMBSIGNAL2 and receiving
COMBSIGNAL2ACK. The job needs a way to keep the value of TVAR.

Plex-C 2

156

Figure 8.21

Interference case 3

In Figure 8.21, the left flow may cause interference, if COMBINEDSIG-
NAL enters at C-level, and then a second COMBINEDSIGNAL enters at
B-level before the C-level job restored variable TVAR. In this case, the B-
level COMBSIGNAL2 destroys TVAR. One way to solve this problem is
to send variable TVAR with COMBSIGNAL2 and get it back in signal
COMBSIGNAL2ACK.

Interference case 4

The fourth and final case shows that it is not a good idea to send a B-level
signal from a C-level job. In Figure 8.22, SIGNALCLEVEL starts a job on
- surprise! - C-level. The job sends a B-level signal before changing varia-
ble STATE to SEBU. However, the B-level signal starts a B-level job
which has a higher priority and interrupts the C-level job. The B-level job
returns a direct signal (or a B-level signal), and by the time variable
STATE is compared with value SEBU, the C-level job has not even exe-
cuted the assignment statement STATE = SEBU yet. Hence, the program
may never get to the task labelled ACTION.

Job Execution

157

Figure 8.22

Interference case 4

Avoiding Variable Interference

There are numerous cases of variable interference, all of them can lead to
fatal consequences in traffic handling. Figure 8.23 shows a number of
strategies to prevent these situations.

Plex-C 2

158

Figure 8.23

Preventing variable interference

Preventing Interrupts

Some tasks require preventing higher level jobs from interrupting the exe-
cution. In this case, two Plex-C procedures make it possible to disable the
interrupt feature of the program administration. For more information, see
chapter 9.7.6, Disable Interrupt, in reference [2].

Figure 8.24

Disabling interrupts

Between DISABLE and ENABLE it is not possible to exit or to send com-
bined signals. Check that this is true for all branches of IF or CASE state-
ments. Otherwise, there may be a system restart.

Sending buffered signals without exiting is permitted, though.

According to reference [1], the maximum execution time between DISA-
BLE and ENABLE is 1 ms. This corresponds to approximately 800 ASA
or 300 Plex-C statements on APZ 211 10/11 processors.

Chapter 9, Size Alteration, contains examples for disabling interrupts.
Here is a small example too.

• Use temporary variables whenever possible. They are always safe.

• When sending and receiving signals, try to save variables by send-

ing them as signal data rather than storing them in DS variables.

• Keep the execution in one SW unit on the same job buffer level, or

at least all subprograms for one function.

• Do not use a DS variable on different job buffer levels.

• If it is really necessary, though, to use a DS variable on different

job buffer levels, the C-level job may prevent interrupts from a
higher level job with DISABLE INTERRUPT.

DISABLE INTERRUPT;

...

! HIGHER LEVEL JOBS CANNOT INTERRUPT !

...

ENABLE INTERRUPT;

Job Execution

159

Example

A job on buffer level C needs to seize a record from the beginning of an
idle linked list. The program sets the state to BUSY and calls statement
block SEIZEIDLEDEVICE. If other parts of the block run on buffer level
B and require access to the same idle linked list, the C-level job needs to
protect itself from unwanted intrusion.

Figure 8.25

Example for DISABLE INTERRUPT

Without disabling the interrupt, a B-level job may break in between
STATE = BUSY and the call to the statement block. Hence, the B-level job
would find an inconsistent idle linked list starting with a record in state
BUSY.

DISABLE INTERRUPT;

RECORDPOINTER:STATE = BUSY;

DO SEIZEIDLEDEVICE;

ENABLE INTERRUPT;

Plex-C 2

160

Chapter Summary

Remember these points from this chapter.

Figure 8.26

Summary

References

[1]

Execution Time Limits
ETX 102 60-1026 Uen
© Ericsson Telecom 1997

[2]

Software Reliability Handbook, Edition 4
EN/LZG 205 603
© Ericsson Telecom 1996

[3]

Plex-C 1 (course book)
especially Chapter 6, Block Interaction
EN/LZT 101 1279 R4B
© Ericsson Telecom 1996

[4]

Limitations in Signal/Event Sending
ETX 102 60-1207 Uen
© Ericsson Telecom 1996

• The APZ uses an interrupt system with several levels, also

called Priority System

• Register Memory (RM) allows jobs to interrupt each other

without losing time by saving data or processor states

• The Job Table is convenient for short, periodic jobs

• 4 Job Buffers, JBA to JBD, allow to prioritise tasks depending

on their urgency

• 4 Time Queues, TQA to TQD, allow to execute jobs when they

are really needed.

• Do not exceed the execution time limits given in the design

rule.

• Follow the C-level rule when creating I/O-handling programs.

• Implement phase division using signals CONTINUEB or

CONTINUEC.

• Always verify the priority level of an incoming buffered signal.

If the job-buffer level is inadequate use level change to switch
priority level.

• Be aware of the constant risk for variable interference.

• Different strategies help to prevent variable interference.

• If necessary, prevent interrupts from higher execution levels.

Job Execution

161

[5]

Selection of Signalling Level
ETX 102 60-1116 Uen (was: XT/UD 81 021)
© Ericsson Telecom 1997

[6]

APZ 21, 8.x; 1993 - 1996, A Presentation
UAB/B/X-96:068 Uen
Ericsson Utvecklings AB 1996

Plex-C 2

162

163

Chapter 9

Size Alteration

Introduction

Most Plex-C programs use files of records. If the number of records in the
file is alterable, the programs need a section for size alteration. Size altera-
tion is always initiated by an exchange technician. This chapter describes
size alteration from an operation and maintenance point of view, as well as
its implementation in Plex-C programs.

Figure 9.1

Chapter Objectives

File Size

The file size is the number of records in a file. The file size can be fixed or
alterable.

Figure 9.2

Fixed and alterable file sizes

Chapter Objectives

After completing this chapter, you are able to:

• Describe local and global size alteration events

• Apply the signals associated with size alteration

• Implement size alteration events in hardware-owning and software-

only blocks

FIXED FILE SIZE

ALTERABLE FILE SIZE

no change of file size

change file size in program sector

with size alteration events

set file size in data sector

set initial file size in data sector

using local number symbol

using 0 (zero) or minimum file size

example:

SIZE OF DATARECORD =

SIZE OF DATARECORD = 0;

ZINDNUM;

CINDNUM = 0;

Plex-C 2

164

Fixed size files of records store the number of records in a local number
symbol such as ZINDNUM. Alterable size files of records store the
number of records in a DS RELOAD variable such as CINDNUM. The
string “indnum” is a twisted acronym for number of individuals. Variable
CINDNUM is RELOAD-marked, because only the exchange technician
may increase or decrease the file size.

Need for Size Alteration

Hardware-owning blocks usually have one record per telephony device or
other pieces of equipment, while software-only blocks assign one record to
each subscriber, call attempt or route.

At initial loading, the operation and maintenance staff need to set the
number of records equal to the number of available devices in the
exchange. Later, when adding or removing devices, or when the exchange
needs more or less traffic-handling capacity, the exchange technician can
lower or raise the number of records accordingly.

Figure 9.3 lists positive and negative aspects of file size alteration.

Figure 9.3

Pros and cons of size alteration

If possible avoid alterable file sizes. Reference [4] contains the following
design rule.

ADVANTAGES

DISADVANTAGES

good memory economy: reserve

inconvenient to the operator: has to

only as many records as needed

check, increase and decrease files

correct dimensioning: assign one

SAEs raise the load in the CP and

record to one item or device

are difficult to administer

SAE programs are difficult to write

and a common source for errors

165

Size Alteration

Figure 9.4

Design rule for size alteration

If the file size does not vary very much, say +/– 20 percent, use a fixed file
size even if some memory in the DS is wasted. Reducing the CP load is
more important here.

Global and Local Size Alteration Events

There are two types of size alteration events.

Figure 9.5

Local versus global SAE

As Figure 9.5 reflects, most exchange technicians find global SAEs easier
to use, since the staff does not need to worry about block names. Neverthe-
less, try not to create new global SAEs, instead combine new files of
records with existing SAEs through some relation, even if this will waste
some memory. See reference [4].

Figure 9.6 shows the available SAE numbers today.

• Avoid SAEs as far as possible. Other solutions such as fixed file

size and sharing an existing SAE must be considered before
choosing an SAE.

• Declare a file with fixed size, if the maximum file size is less than

50 kW, word-length 16 bits.

• When deciding for a fixed file size, choose a “safe” number of

records. In other words, the file should have enough records to be
congestion-free in all applications.

• Global size alteration events change one or several files in one or

several blocks. Global SAEs allow to combine several files
belonging to the same function in several blocks.

• With global SAEs, the exchange technician does not have to adapt

the size of each file separately.

• Local size alteration events change one or several files in one

block only. To identify one local SAE, the exchange technician
specifies the block name and the SAE number which only helps to
distinguish different files in a block.

• With local SAEs, the exchange technician knows exactly which

block is affected.

Plex-C 2

166

Figure 9.6

Size alteration event numbers

Table 9.1 shows recommended SAE numbers for typical local size altera-
tion events.

Table 9.1

Descriptions for SAEs

Operating of Size Alteration

This segment introduces AXE commands and printouts for file size altera-
tion. Furthermore, the text describes scenarios of successful and rejected
size alterations.

The following pictures include these command parameters.

SAE Number

Description

500

Number of devices/task individuals

501

Number of subscriber individuals

504

Number of route individuals

515

Number of DIPs
<DIP = digital path>

528

Number of SNT types
<SNT = switching network terminal>

529

Number of SNT individuals

600-601

Hardware-related SAEs

602-603

Subscriber-related SAEs

604-606

Traffic-sensitive SAEs

607-610

Translation-related SAEs

000–299

APT

APZ

global

local

global

local

800 – 899

1800 –1999

300 – 424

500-799

425 – 499

900-1799

167

Size Alteration

•

sizealterationevent= number of size alteration event
value range 0 up to 1999

•

filesize

= new number of records, “individuals”

•

blockname

= name of block containing file(s) of records

Also note that NI is an abbreviation for number of individuals, i.e. records.

Figure 9.7 lists the commands for local size alteration events.

Figure 9.7

Commands for local SAEs

Figure 9.8 lists the same commands for global size alteration events, the
only differences being parameter BLOCK missing.

Figure 9.8

Commands for global SAEs

For more details about commands SAAII and SAADI, see their command
descriptions, references [6] and [7], as well as their common printout
description, reference [5].

Block SAF

APZ block SAF receives these commands and administers size alteration
events. SAF checks if the increase or decrease operation is valid. For
instance, block SAF rejects command SAAII and prints an error message,
if the current file size is larger than the new file size. Similarly, block SAF

Size Increase

SAAII:BLOCK=blockname,SAE=sizealterationevent,NI=filesize;

Size Decrease

SAADI:BLOCK=blockname,SAE=sizealterationevent,NI=filesize;

Printout of File Size

SAAEP:BLOCK=blockname,SAE=sizealterationevent;

Size Increase

SAAII: SAE=sizealterationevent,NI=filesize;

Size Decrease

SAADI: SAE=sizealterationevent,NI=filesize;

Printout of File Size

SAAEP:SAE=sizealterationevent;

Plex-C 2

168

rejects command SAADI and prints an error message, if the current file
size is smaller than the new file size.

CPREPNUM and CINDNUM

SW units with files permitting size alterations use two variables to indicate
the number of records. Figure 9.9 explains their difference.

Figure 9.9

CPREPNUM and CINDNUM

Example

•

A file has, say, 200 records. Hence, both CINDNUM and CPREP-
NUM are equal to 200.

•

The exchange technician orders a size decrease to 150 records with
command SAADI.

•

The SW unit keeping the file sets CPREPNUM to 150, while CIND-
NUM remains at 200. The program rebuilds the idle list with records
from 0 to 149. When the program seizes an idle record from the linked
list, records with numbers 150 through 199 are no longer available.

•

When records between 150 and 199 become idle, they are not
appended to the idle linked list.

•

If all records between 150 and 199 are idle, the size alteration suc-
ceeds and the size-alteration function orders the program to set
CINDNUM = CPREPNUM = 150 .

Record Files without Linked Lists

Even files without linked lists need variable CPREPNUM. In this case,
CPREPNUM - 1 indicates the number of the highest available record when

CPREPNUM

• number of records available to applications

• append only new idle records up to number CPREPNUM - 1 to

the idle linked list. Code example:

BEGIN APPENDIDLE;

! statement block !

IF RECORDPTR < CPREPNUM THEN

! append record at end of linked list !

FI;
END APPENDIDLE;

CINDNUM

• number of records existing in data store

• identical to CPREPNUM except when preparing for a size

decrease; then, CPREPNUM is equal to the new lower file size
to prevent applications from seizing records in the decrement
area

169

Size Alteration

scanning the file of records. The following code example shows how to
find an idle record in a file:

FOR FIRST

RECORDPTR FROM CPREPNUM - 1

WHERE STATE = ZIDLE5

....

Conclusion

For files with and without linked lists, do not use variable CINDNUM in
traffic handling or other applications.

Size Alteration Troubles

Size alterations may fail in various situations. The block designer writes a
operations and maintenance document, the 2/Application Information
which describes the exchange data in a block. This always includes the
alterable size of a file of records.

2/Application Information

The abbreviation for this document is 2/AI. The 2/AI gives the following
information to the exchange technician.

•

minimum file size (optional)

•

maximum file size (optional)

•

maximum increase step

•

maximum decrease step (optional)

At a file size increase, the number of new records is limited. Otherwise, the
size alteration event would take too much CP time. Especially reserving
space for the new records and initialising their variables requires a signifi-
cant amount of CP time. Hence, maximum increase step is limited, in
many programs the limit is 500.

A similar argument applies to file size decrease, where the number of
records disappearing may be limited.

The SAE does not succeed, if the requested size increase or decrease vio-
lates any of these four conditions.

Other Problems

On top of this, other difficulties may occur.

•

size increase: new file size is lower than current file size

•

size decrease: new file size is larger than current file size

•

size decrease: records to disappear are busy or blocked etc.

Again, the SAE fails if any of these situations occur.

Plex-C 2

170

Size Alteration Scenarios

The following scenarios present and analyse successful and unsuccessful
cases of changing the file size. For more details about commands SAAII
and SAADI, see their command descriptions, references [6] and [7], as
well as their common printout description, reference [5].

Scenario 1

The exchange technician successfully raises the number of records by 60.

Figure 9.10

SAE scenario 1

Scenario 2

The exchange technician fails to raise the number of records by 600,
because the command exceeds the maximum increase step of, e.g. 500.

Figure 9.11

Scenario 2

Block SAF rejects this command, prints an error message and exits.

Scenario 3

The exchange technician successfully lowers the number of records by 50.
All records in the decrement area, that is, records 150 to 199, have STATE
IDLE, and the decrease succeeds.

Size Increase

SAAII:BLOCK=foo,SAE=500,NI=260;

CPREPNUM

CINDNUM

200

260

200

260

Size Increase

SAAII:BLOCK=foo,SAE=500,NI=800;

CPREPNUM

CINDNUM

200

171

Size Alteration

Figure 9.12

Scenario 3

Preparing the size decrease, the file-owning SW unit sets CPREPNUM to
150. That way, application subprograms in the SW unit can no longer
access records 150 to 199. Finally, upon completion of the size decrease,
the SW unit sets both CPREPNUM and CINDNUM to 150.

Scenario 4a

Again, the exchange technician tries to lower the number of records by 50.
This time, however, some records in the decrement area, that is, records
150 to 199, have STATE BUSY, and the decrease fails. Block SAF rejects
the command and prints an error message.

Figure 9.13

Scenario 4a

After the failure, variable CPREPNUM remains 150. That way, new traffic
cases can only seize records with numbers 0 to 149. There are still 200
records in the data store, though, as variable CINDNUM indicates.

Two Choices

It is the job of the exchange technician to solve this inconsistent situation.
There are two alternatives.

Size Decrease

SAADI:BLOCK=foo,SAE=500,NI=150;

CPREPNUM

CINDNUM

200

150

200

150

Size Decrease

SAADI:BLOCK=foo,SAE=500,NI=150;

CPREPNUM

CINDNUM

200

150

200

150

Record 160: STATE=BUSY
Record 169: STATE=BUSY

Plex-C 2

172

The exchange technician repeats the size decrease after waiting
some minutes. Hopefully all devices in the decrement area became
idle. See “Scenario 4b” on page 172.

The exchange technician increases the number of records to the orig-
inal file size, or even larger than that. See “Scenario 4c” on
page 172.

Scenario 4b

The previous size decrease failed. Having waited some minutes, the
exchange technician tries again.

This time, all records in the decrement area are in STATE IDLE and the
size decrease succeeds.

Figure 9.14

Scenario 4b

Scenario 4c

The previous size decrease failed. The exchange technician gives in, and
raises the number of records to the original file size again.

Figure 9.15

Scenario 4c

Size Decrease

SAADI:BLOCK=foo,SAE=500,NI=150;

CPREPNUM

CINDNUM

150

200

150

Record 160: STATE=IDLE
Record 169: STATE=IDLE

Size Increase

SAAII:BLOCK=foo,SAE=500,NI=200;

CPREPNUM

CINDNUM

150

200

Record 160: STATE=BUSY
Record 169: STATE=BUSY

173

Size Alteration

Keep all these scenarios and possibilities in mind when programming size
alteration events in an APT SW unit.

SAE Signalling

The remainder of this chapter discusses the implementation of size altera-
tion events in file-owning APT blocks. APZ block SAF sends three differ-
ent signals to start and supervise the size alteration in the file-owning
programs. Figure 9.16 provides a first overview. For more details about
signal data, see “Signal Descriptions” on page 189.

Figure 9.16

SAE Signalling

SAF

Block with SAE

GIVEFS

Check if Block participates in SAE.

GIVEFSEND

Block returns if it participates, if so it sends
the number of files involved in SAE, otherwise
whether the Block wants to be informed about
the SAE in question.

CONTFS

Check if SAE is permitted. Max. increase step
exceeded? Any records in decrement area
not idle? Etc.

CONTFSEND

Block returns if SAE is permitted.
If not, it sends a code specifying the reason
for the rejection.

SETFS

SAE is valid, SAF created new records in DS.
Set new file size (CINDNUM, CPREPNUM)
and, in size increase, initialise new records.

SETFSEND

SAE finished, new records are accessible.

Plex-C 2

174

SAE Administration

This section describes briefly how block SAF administers a size alteration
event. See also references [2] and [8].

Figure 9.17

SAF administers SAEs (part 1)

How come block SAF sends signal GIVEFS twice, in steps

➌

and

➎

? The

reason is that block SAF cannot memorise all the data it receives with return
signal GIVEFSEND. The block with SAE may contain several files of
records participating in the same SAE. In steps

➌

and

➎

, block SAF sends

signal GIVEFS once for each participating file and performs the necessary
checks in steps

❹

and

➏

Figure 9.18 contains the continuation of the size alteration. Note that block
SAF loops over the steps shown. For a global SAE, block SAF loops over
all participating blocks. For any type of SAE, block SAF loops over all par-
ticipating files of records in the block. For instance, block SAF repeats
steps

➐

➑

and

➒

in one loop (one iteration per file per block).

Observe that the actual size alteration takes place in the last two steps,

❶➋

and

❶➌

, only. All activities prior to

❶➋

and

❶➌

are only checks and pre-

paratory steps.

❶

Check if any store allocation function is in progress. If so, reject the

command and print FUNCTION BUSY.

➋

SAF asks LARI if block with SAE has BCEXTREC in block type ext.

➌

If so, SAF sends GIVEFS to block with SAE to check if block partici-

pates and to obtain number of participating files, their maximum size

and their internal ordinal number.

❹

SAF checks if SAE is going in “wrong direction”.

➎

SAF sends GIVEFS again (!) to obtain the same info as in

➌

➏

SAF checks if the new file size exceeds the maximum file size.

175

Size Alteration

Figure 9.18

SAF administers SAEs (part 2)

SAE Flowcharts

This section contains flowchart proposals for the file-owning SW units. In
addition, small code segments show the signal reception and sending state-
ments including the essential parameter values. See also reference [1].

Local modifications due to hardware or software specifications in your
design project may occur! However, do not follow the sample code in ref-
erence [2], the program is not sufficient.

This section contains three segments.

•

Reception of GIVEFS

•

Reception of CONTFS

•

Reception of SETFS

➐

SAF sends CONTFS to each file-owning block to check if the SAE is

permitted.

➑

SAF receives CONTFSEND indicating whether the alteration suc-

ceeds, and if not, the signal carries a reason code.

➒

If a record in the decrement area is not IDLE at size decrease, block

SAF repeats sending CONTFS after 30 seconds. If the alteration is still

not permitted, SAF interrupts the execution and prints an error mes-

sage.

➓

At size increase, SAF checks if there is sufficient space in the data

store.

❶❶

SAF sends GIVEFS again (!) to obtain the same info as in

➌

❶➋

SAF orders space for the new records in the data store.

❶➌

SAF sends SETFS requesting the file-owning blocks to initialise vari-

ables in the new records and to set CINDNUM/CPREPNUM to the

new file size.

Plex-C 2

176

Reception of GIVEFS

Figure 9.19

Flowchart GIVEFS part 1(1)

In Figure 9.19, the file-owning block participates in SAE500. Other pro-
grams support other size alteration events.

The sample code in the remainder of this chapter assumes that the file-
owning block has only one file of records participating in the SAE. This
does not affect the flowcharts much, but simplifies the signal transmission
statements. See Figure 9.20 and compare with the signal descriptions at
the end of this chapter.

GIVEFS
[SAF

Size alteration
event, SAE

SAE500

Size alteration
event allowed

FILENUMBER
FOR STATE

GIVEFSEND
/* BLOCK TAKES PART
IN SAE */
[SAF

OTHER

Size alteration
event not allowed

GIVEFSEND
/* BLOCK DOES NOT
TAKE PART IN SAE */
[SAF

177

Size Alteration

Figure 9.20

GIVEFS and GIVEFSEND

>>>>>>>>>>>>>>>>>>

GIVE FILE SIZE

GIVEFS

CHANGE DATA

>>>>>>>>>>>>>>>>>>

ENTER GIVEFS WITH

TSAEVENT;

...

SEND ACKNOWLEDGEMENT TAKES PART IN THIS SAE

-------------------------------------------

SEND GIVEFSEND WITH

ZTAKEPART1,

TFILENUMBER,

ZNOTMASTERFIXSIZE1,

ZNODIVERGENCE1,

ZNOMULTIPLY1,

ZMAXSIZENOTGIVEN0,

ZNOSUPERVISION65535,

ZNOADDRECORDS0;

EXIT;

...

DOES NOT TAKE PART IN THIS SAE

------------------------------

SEND GIVEFSEND WITH

ZDOESNOTTAKEPART256;

EXIT;

Plex-C 2

178

Reception of CONTFS

Figure 9.21

Flowchart CONTFS part 1(4)

CONTFS
[SAF

TNEWINDNUM < CINDNUM

YES
/* SIZE DECREASE */

DECREASE TOO LARGE
CINDNUM-TNEWINDNUM>ZMAXSTEP

CONTFS10

YES

TREASON =
ZSIZEERROR42

SET SAE NOT PERMITTED

CONTFSEND
[SAF

NO
/* SIZE INCREASE */

CONTFS30

[P.7

[P.9

179

Size Alteration

Figure 9.22

Flowchart CONTFS part 2(4)

CONTFS10

DISABLE INTERRUPT
CPREPNUM = 0
CFIRST = ZNIL
ENABLE INTERRUPT

FOR ALL RECORDS
FROM 0 UPTO TNEWINDNUM-1

DISABLE INTERRUPT

CPREPNUM = CPREPNUM + 1

STATE

IDLE

APPENDIDLE
/* ADD IDLE RECORD TO
END OF IDLE LINKED LIST */

ENABLE INTERRUPT

PHASE DIVISION NECESSARY

FOR ALL RECORDS
FROM 0 UPTO TNEWINDNUM-1

CONTFS20

YES

SEND AND RECEIVE
SIGNAL CONTINUEC

OTHER

[P.6

[P.8

Plex-C 2

180

Figure 9.23

Flowchart CONTFS part 3(4)

CONTFS20

FOR FIRST RECORD
BETWEEN CINDNUM-1 AND TNEWINDNUM

STATE

IDLE

PHASE DIVISION NECESSARY

FOR FIRST RECORD
BETWEEN CINDNUM-1 AND TNEWINDNUM

SET SAE PERMITTED

CONTFSEND
[APZ

YES

SEND AND RECEIVE
SIGNAL CONTINUEC

OTHER

TREASON =
ZSIZEERROR47

SET SAE NOT PERMITTED

[P.7

181

Size Alteration

Figure 9.24

Flowchart CONTFS part 4(4)

CONTFS30

INCREASE TOO LARGE
TNEWINDNUM-CINDNUM>ZMAXSTEP

SET SAE PERMITTED

CONTFSEND
[SAF

YES

TREASON =
ZSIZEERROR22

SET SAE NOT PERMITTED

/* SIZE INCREASE */

[P.6

Plex-C 2

182

Figure 9.25

CONTFS and CONTFSEND

>>>>>>>>>>>>>>>>>>

CONTROL IF ALTERATION

CONTFS

CAN TAKE PLACE

>>>>>>>>>>>>>>>>>>

ENTER CONTFS WITH

TNEWINDNUM;

...

SEND ACKNOWLEDGEMENT SAE PERMITTED

----------------------------------

SEND CONTFSEND WITH

ZPERMITTED0;

EXIT;

...

SEND ACKNOWLEDGEMENT SAE NOT PERMITTED

--------------------------------------

SEND CONTFSEND WITH

ZNOTPERMITTED2,

TREASON;

EXIT;

183

Size Alteration

Reception of SETFS

Figure 9.26

Flowchart SETFS part 1(4)

SETFS
[APZ

TNEWINDNUM > CINDNUM

YES
/* SIZE INCREASE */

CPREPNUM < CINDNUM

YES
/* SIZE DECREASE
PREPARED EARLIER */

SETFS10

SETFS20

NO
/* SIZE DECREASE */

SETFS30

[P.11

[P.12

[P.13

Plex-C 2

184

Figure 9.27

Flowchart SETFS part 2(4)

SETFS10

/* SIZE INCREASE,
BUT SIZE DECREASE PREPARED EARLIER
RECONSTRUCT IDLE LINKED LIST */

TSCANSTART = CPREPNUM
/* SAVE INITIAL VALUE OF CPREPNUM */

FOR ALL RECORDS
FROM TSCANSTART UPTO CINDNUM-1

DISABLE INTERRUPT

CPREPNUM = CPREPNUM + 1

STATE

IDLE

APPENDIDLE
/* ADD NEW IDLE RECORD
TO END OF IDLE LINKED LIST */

ENABLE INTERRUPT

PHASE DIVISION NECESSARY

FOR ALL RECORDS
FROM CPREPNUM UPTO CINDNUM-1

SETFS20

YES

SEND AND RECEIVE
SIGNAL CONTINUEC

OTHER

[P.10

[P.12

185

Size Alteration

Figure 9.28

Flowchart SETFS part 3(4)

SETFS20

/* BUILD NEW TEMPORARY IDLE
LINKED LIST
NOTE: HW DEVICE RECORDS SET STATE
TO BLOCKED AND DO NOT APPEND TO
LINKED LIST! */

FOR ALL NEW RECORDS
BETWEEN CINDNUM AND TNEWINDNUM-1

SET STATE TO IDLE

APPENDIDLETOTEMP
/* ADD NEW IDLE RECORD TO END OF
TEMPORARY IDLE LINKED LIST */

PHASE DIVISION NECESSARY

FOR ALL NEW RECORDS
BETWEEN CINDNUM AND TNEWINDNUM-1

DISABLE INTERRUPT

MERGELINKEDLISTS
/* APPEND TEMPORARY IDLE LIST AT END
OF REGULAR IDLE LINKED LIST */

SETFS40

YES

SEND AND RECEIVE
SIGNAL CONTINUEC

[P.10,11

[P.13

Plex-C 2

186

Figure 9.29

Flowchart SETFS part 4(4)

Figure 9.30

SETFS and SETFSEND

SETFS30

/* SIZE DECREASE */

DISABLE INTERRUPT

CINDNUM = TNEWINDNUM
CPREPNUM = CINDNUM
ENABLE INTERRUPT

SETFSEND
[APZ

SETFS40

/* SIZE INCREASE */

[P.10

[P.12

>>>>>>>>>>>>>>>>>>

SET FILE SIZE

SETFS

>>>>>>>>>>>>>>>>>>

ENTER SETFS WITH

TNEWINDNUM;

...

SEND ACKNOWLEDGEMENT FILE SIZE SET

----------------------------------

SEND SETFSEND;

EXIT;

187

Size Alteration

SAE for HW and SW Files

Mind the following differences when programming files whose records
correspond to hardware devices. Note that Figure 9.28 reflects initialising
new records in a file without any connection to hardware equipment.
Observe the following differences which apply to HW files.

•

New device records get the initial STATE BLOC or ZBLOC0.

•

Do not append new device records at the end of the idle list.

•

It is the job of the exchange technician to deblock the devices and
device records with various AXE commands.

Connecting and Deblocking a Device

This section is only relevant to designers in charge of hardware-owning
blocks! Reference [10] is the basis for this section.

To understand the necessary commands, please study the bits in record
variables ADMSTATE, connection state of a device, and BLSTATE, rea-
sons for blocking of a device.

Remember the interpretation of their bits.

•

ADMSTATE: bit = 0 means connection active

•

BLSTATE:

bit = 1 means blocking active

Plex-C 2

188

Figure 9.31

ADMSTATE and BLSTATE

The device is
connected to

ADMSTATE

ROUTE

GSS

EMCON

GSCON

SSCON

RCON

The device is
blocked

BLSTATE

Automatically

TEST

CONTROL

MANUAL

MBL

BLM

BLT

BLO

189

Size Alteration

Table 9.2 lists the essential commands to take a device into service. Step-
by-step, the commands connect devices and then remove blocking condi-
tions. The table also includes the names of the signals sent by the com-
mand-handling SW units.

Table 9.2

Connecting and deblocking a device

Signal Descriptions

This section contains printouts of all signal descriptions relevant in size
alteration events. These documents reflect reference [9]. When creating
new software, please make sure that these versions of the signals apply to
your design project and source system.

OUTE

GSS

utomatic

TEST

CONTR

MANU

Command

Signal

Function

ADMSTATE

BLSTATE

SAAII

SETFS

Size alteration increase

EXEMI

EMINFO

Connect device to EM

BLEME

EMDBLD

Deblock EM

EXDSI

WSSCON

Connect device to SS

EXDGI

WGSCON

Connect device to GS

EXDRI

WDD

Connect device to route

BLODE

SMDBLOC

Deblock device

Plex-C 2

190

Figure 9.32

GIVEFS

DOCUMENT GIVEFS;

SIGNAL GIVEFS;

! ID “664/155 14 - APZ 210 !

!FUNCTION: GIVE SIZE ALTERATION DATA PER FILE!

TYPE 1 MULTIPLE CP-CP; ! SINGLE SIGNAL !

!POSSIBLE RETURN SIGNAL: GIVEFSEND!

!COMMUNICATION: SENDER: SAF

RECEIVER: USER!

LEVEL C BUFFER;

DATA D1 16, ! SIZE ALTERATION EVENT !

D2 16; ! FILE POINTER !

!DETAILED DATA DESCRIPTION:

D2 0 = FIRST FILE IN EVENT

. 1 = SECOND FILE IN EVENT

. ETC.!

END SIGNAL;

191

Size Alteration

Figure 9.33

GIVEFSEND

DOCUMENT GIVEFSEND;

SIGNAL GIVEFSEND;

“665/155 14 - APZ 210”!

!FUNCTION: SIZE ALTERATION DATA IS GIVEN PER FILE!

TYPE 1 CP-CP; ! SINGLE SIGNAL !

!RETURN SIGNAL TO: GIVEFS!

!COMMUNICATION: SENDER: USER
RECEIVER: SAF!
LEVEL C BUFFER;

DATA D1 16, ! CODE OF INTEREST !
D2 16, ! ORDINAL NUMBER OF THE FILE !
D3 16, ! RELATION TO OTHER FILES !
D4 T, ! DIVERGENCE FROM GIVEN NUMBER OF RECORDS !
D5 16, ! DIVERGENCE FACTOR !
D6 R, ! MAXIMUM FILE SIZE !
D7 R, ! NUMBER OF USED INDIVIDUALS !
D8 R; ! ADDITIONAL NUMBER OF RECORDS !

!DETAILED DATA DESCRIPTION:
D1 0 = DOES NOT TAKE PART WITH FILE BUT IS INTERESTED
. OF THE EVENT
. 1-255 = TAKE PART WITH GIVEN NUMBER OF FILES
. 256 = DOES NOT TAKE PART IN ACTUAL SIZE ALTERATION EVENT

D3 0 = NOT MASTER FILE, NO FIX SIZE
. 1 = NOT MASTER FILE, FIX SIZE
. 2 = MASTER FILE, NO FIX SIZE
. 3 = MASTER FILE, FIX SIZE

D4 1 = NO DIVERGENCE FROM GIVEN NUMBER, FACTOR GIVEN IN D5
MUST BE 1
. 2 = GIVEN NUMBER IS TO BE MULTIPLIED WITH FACTOR GIVEN
IN D5
. 3 = GIVEN NUMBER IS TO BE DIVIDED WITH FACTOR GIVEN IN D5
. 5 = NUMBER GIVEN IN D8 IS TO BE ADDED TO GIVEN NUMBER
. 6 = GIVEN NUMBER IS TO BE MULTIPLIED WITH FACTOR IN D5
. AND NUMBER IN D8 ADDED
. 7 = GIVEN NUMBER IS TO BE DIVIDED WITH FACTOR IN D5 AND
. NUMBER IN D8 ADDED

D6 0 = MAXIMUM FILE SIZE IS 64K INDIVIDUALS
. 0 > MAXIMUM FILE SIZE IS GIVEN VALUE BUT LARGER THEN
1 AND LESS THEN 64K INDIVIDUALS
H’FFFF = MAXIMUM FILE SIZE IS 64K INDIVIDUALS
. RNIL = MAXIMUM FILE SIZE IS SYSTEM LIMIT, I.E IN APZ 211
64K INDIVIDULS AND IN APZ 212 BEYOND 64K INDIVIDUALS

D7 USED FOR FUNCTION SUPERVISION OF UTILIZATION IN FILES
. 0 >= NUMBER OF USED INDIVIDUALS IS GIVEN VALUE
(H’FFFF IS VALID FOR >64K FILES)
H’FFFF = SUPERVISION NOT REQUIRED FOR NOT >64K FILES
. RNIL = SUPERVISION NOT REQUIRED FOR >64K FILES

EXAMPLE TO D4, D5 AND D8 :
NUMBER OF RECORDS IN FILE = GIVEN NUMBER / 16 + 3
GIVES D4=7, D5=16 AND D8=3!
END SIGNAL;

Plex-C 2

192

Figure 9.34

CONTFS

DOCUMENT CONTFS;

SIGNAL CONTFS;

! ID“666/155 14 - APZ 210” !

!FUNCTION: CONTROL IF THE ALTERATION CAN TAKE PLACE!

TYPE 1 MULTIPLE CP-CP; ! SINGLE SIGNAL !

!POSSIBLE RETURN SIGNAL: CONTFSEND!

!COMMUNICATION: SENDER: SAF

RECEIVER: USER!

LEVEL C BUFFER;

DATA D1 16, ! SIZE ALTERATION EVENT !

D2 16, ! FILE POINTER !

D3 T; ! NEW NUMBER OF RECORDS !

!DETAILED DATA DESCRIPTION:

D2 0 = FIRST FILE IN EVENT

. 1 = SECOND FILE IN EVENT

. ETC.!

END SIGNAL;

193

Size Alteration

Figure 9.35

CONTFSEND

In Figure 9.35, note that signal data word D2 indicates the local fault code.
This code corresponds to the “user code” in the result printout for com-
mands SAAII and SAADI. The printout description, reference [5], con-
tains a complete list of valid user codes. Use D2 only when rejecting the
change in file size.

DOCUMENT CONTFSEND;

SIGNAL CONTFSEND;

! ID“667/155 14 - APZ 210”!

!FUNCTION: ANSWER TO IF THE ALTERATION CAN TAKE PLACE!

TYPE 1 CP-CP; ! SINGLE SIGNAL !

!RETURN SIGNAL TO: CONTFS!

!COMMUNICATION: SENDER: USER

RECEIVER: SAF!

LEVEL C BUFFER;

DATA D1 16, ! CODE !

D2 16; ! CODE FOR REASON !

!DETAILED DATA DESCRIPTION:

D1 0 = ALTERATION PERMITTED

. 1 = ALTERATION NOT PERMITTED

. 2 = ALTERATION NOT PERMITTED.

CODE FOR REASON IS GIVEN IN D2

D2 WILL BE PRINTED OUT OR SENT AS A COMPLEMENT

TO A LOCAL FAULT CODE!

!MISCELLANEOUS INFORMATION!

END SIGNAL;

Plex-C 2

194

Table 9.3 shows a few recommended reason codes/user codes (text simpli-
fied).

Table 9.3

Reason codes for rejecting SAEs

Reason Code

Description

Size increase rejected. Risk of interference
with other function in progress. Come back
later with same command.

Too large increase step. Takes too long time.
Perform the increase in several small steps.

Some other size alteration event is to be per-
formed before the size increase.

Size decrease rejected. Risk of interference
with other function in progress. Come back
later with same command.

Too large reduction step. Takes too long time.
Perform the decrease in several smaller
steps.

At least one individual not idle. The individu-
als to be removed are marked IDLE succes-
sively and are no longer used. Come back
later with the same command. If necessary,
repeat the command a number of times until
the size alteration event is completed.

195

Size Alteration

Figure 9.36

SETFS

DOCUMENT SETFS;

SIGNAL SETFS;

! ID“668/155 14 - APZ 210”

!FUNCTION: SET FILE SIZE (INDNUM VARIABEL)!

TYPE 1 MULTIPLE CP-CP; ! SINGLE SIGNAL !

!POSSIBLE RETURN SIGNAL: SETFSEND!

!COMMUNICATION: SENDER: SAF

RECEIVER: USER!

LEVEL C BUFFER;

DATA D1 16, ! SIZE ALTERATION EVENT !

D2 16, ! FILE POINTER !

D3 T; ! NUMBER OF RECORDS !

!DETAILED DATA DESCRIPTION:

D2 0 = FIRST FILE IN EVENT

. 1 = SECOND FILE IN EVENT

. ETC.!

END SIGNAL;

Plex-C 2

196

Figure 9.37

SETFSEND

Chapter Summary

Remember these points from this chapter.

Figure 9.38

Summary

DOCUMENT SETFSEND;

SIGNAL SETFSEND;

! ID“669/155 14 - APZ 210”!

!FUNCTION: FILE SIZE IS SET!

TYPE 1 CP-CP; ! SINGLE SIGNAL !

!RETURN SIGNAL TO: SETFS!

!COMMUNICATION: SENDER: USER

RECEIVER: SAF!

LEVEL C BUFFER;

END SIGNAL;

• Files with fixed size set their size in the data sector.

• Files with alterable size initialise their size in the data sector

and set it in size alteration events in the program sector.

• Global SAEs affect files in several blocks, local SAEs concern

files in one block.

• Variable CPREPNUM contains the number of records available

to applications. Variable CINDNUM contains the number of
records in the data store.

• Block SAF sends signals GIVEFS, CONTFS and SETFS to

request and supervise size alterations.

• Follow the flowcharts provided when programming size altera-

tion events. Additional variations, e.g. more checks, may occur.

197

Size Alteration

References

[1]

Size Alteration of Files with Linked Lists (DR)
X/U 159-78 808
© Ericsson Telecom 1978

[2]

Software Reliability Handbook, Edition 4
EN/LZG 205 603
© Ericsson Telecom 1996

[3]

Plex-C 1 (course book)
especially Chapter 6, Block Interaction
EN/LZT 101 1279 R4B
© Ericsson Telecom 1996

[4]

Selection of Size Alteration Event (DR)
ETX 102 60-1030Uen
© Ericsson Telecom 1996

[5]

Size Alteration Result (POD)
2/190 83-CNZ 211 105 Uen
© Ericsson Telecom 1992

[6]

Size Alteration Event Decrease Initiate (SAADI; COD)
1/190 82-CNZ 211 105 Uen
© Ericsson Telecom 1992

[7]

Size Alteration Event Increase Initiate (SAAII; COD)
2/190 82-CNZ 211 105 Uen
© Ericsson Telecom 1992

[8]

Function Block SAF (Block Description)
1551-CNZ 211 105 Uen
© Ericsson Telecom 1988

[9]

Signal Descriptions:
GIVEFS

664/155 14-APZ 210

GIVEFSEND

665/155 14-APZ 210

CONTFS

666/155 14-APZ 210

CONTFSEND 667/155 14-APZ 210
SETFS

668/155 14-APZ 210

SETFSEND

669/155 14-APZ 210

[10] Connecting and Deblocking a Device

Internal note by EEI Paul Stynes
Contact Paul for further details

Plex-C 2

198

199

Chapter 10

Job Table Signals

Introduction

Job table signals start short, periodic jobs. Unlike other signals, they do not
carry any data and have the highest execution priority, traffic-handling
level 1.

Figure 10.1

Chapter Objectives

Concept

Job table signals activate short, periodic jobs. The job table sends signals
automatically to the receiving SW units at intervals specified in the pro-
gram sector of the SPI. The signals are not buffered, and do not carry any
data.

Job table signals have the highest execution priority and run on THL 1
(traffic-handling level 1). Therefore, very strict execution time limits
apply. See section Execution Time Limits in reference [3] for details. The
execution time for any Enter-to-Exit segment on THL 1 is limited to 0.1
msec, which corresponds to approx. 80 Plex-C statements on APZ 212 10/
11 processors.

Job table signals help to implement routines for time supervision, time
measurement or short, periodic jobs. Do not use them, however, to delay or
interrupt the program execution for a certain time. In this case, insert any
regular buffered signal in a relative time queue with the

SEND ... DELAY ...

statement. For a discussion of time measure-

ment and time supervision, please refer to Chapter 11, Time Supervision
and Time Measurement, below.

Regular signal descriptions apply for job table signals. The Plex-C state-
ments

TYPE 1 MULTIPLE CP-CP

and

LEVEL NO BUFFER

should

appear in the description of job-table signals. Take a look at the signal
description for CLTIME0, for instance, document number 600/155 14-
APT 210.

Chapter Objectives

After completing this chapter you are:

• Able to understand the concept of job table signals

• Able to write Plex-C statements for job table signals

• Aware of the restrictions of using job table signals

Plex-C 2

200

Plex-C Statements

This section explains how to put signals into the job table, how to receive
job table signals in the program sector and how to reset the interval to the
next time the signal is sent. The last statement shows how to remove sig-
nals from the job table.

Inserting a Signal in the Job Table

In this example, the Plex procedure JOBTABLE INSERT stores signal
CLTIME0 in the job table. The indicated time interval is 100 cs or csec,
which is equal to 1 sec.

After a certain time interval, the job table sends signal CLTIME0 to the
current CP software unit. Note that the job administration adds a random
interval of 0 - 150 ms to the first indicated time interval to obtain a bal-
anced use of the job table. Consequently, the time interval for the first
sending of signal CLTIME0 is between 1 and 1.15 sec.

The procedure JOBTABLE generates combined signal sending. For this
reason, temporary variables and pointers have undefined values after the
procedure.

The system restart routines erase the job table. Therefore, Plex-C pro-
grams need to restore job table signals in the job table after every restart.

Receiving a Job Table Signal in the Program Sector

There is no difference between receiving buffered and job table signals.
Both types of signals use statement ENTER. Since job table signals cannot
carry any data, they cannot have the

WITH

part in the ENTER statement.

Resettting the Time Interval for a Job Table Signal

This Plex procedure sets the time interval for a signal stored in the job
table. Insert this procedure after receiving a signal from the job table and
before the next EXIT statement, if the job table should send the periodic
signal again. Otherwise, if the program no longer needs the periodic sig-

JOBTABLE INSERT CLTIME0 INTERVAL IS 100 CS [,

POINTER IS DEVPTR] ;

ENTER CLTIME0;

INTERVAL IS 50 CS;

Job Table Signals

201

nal, remove the signal from the job table with the JOBTABLE DELETE
procedure (see below).

Note that this time interval is more accurate, because the job table does not
add a random time interval to the specified waiting time after INTERVAL
IS.

Removing a Signal from the Job Table

This procedure removes the program’s signal CLTIME0 from the job
table. Insert this statement whenever the SW unit does not need the job
table signal for a longer time. Some programs, however, never use this
statement, since they require continuous input from the job table.

Consider the following example in Figure 10.2.

Complete Example

Figure 10.2

Typical code segement with a job-table signal

JOBTABLE DELETE CLTIME0 [,

POINTER IS DEVPTR] ;

JOBTABLE INSERT CLTIME0 INTERVAL IS 100 CS;

...

EXIT;

...

ENTER CLTIME0;

IF RUNNINGJOBS = 1 THEN

INTERVAL IS 50 CS;

SEND CONTINUEC REFERENCE COWNREF

WITH OWNPOINTER, ... ;

ELSE

JOBTABLE DELETE CLTIME0;

FI;

EXIT;

ENTER CONTINUEC WITH OWNPOINTER, ... ;

! EXECUTING THE "REAL" WORK !

Plex-C 2

202

The example shows that signal CLTIME0 is stored in the job table at some
stage of the program. This may be the start/restart section of the program,
but the program may also use JOBTABLE INSERT later when the peri-
odic signal is really needed by the program.

A regular EXIT statement concludes the insertion of CLTIME0 in the job
table.

After the ENTER CLTIME0 statement, the program can either reset the
time interval for the job table signal, if more jobs in the program require
this signal, or the program can remove the signal from the job table.

In case the program has to execute some further tasks, they should run on
job buffer level B or C. Consequently, continue execution on the desired
job buffer level using buffered signals CONTINUEB, CONTINUEC or
CLSCAN0. EXIT terminates the job on THL 1 then.

Restrictions

Although job table signals use the highest execution priority (THL 1), the
specified time intervals may not be kept with great accuracy. The reason is
that even THL 1 jobs cannot interrupt on-going jobs on job buffer levels A
and B. All three priority levels share the same set of register memory.

If several job table signals are needed by the same program, use signals
CLTIME0, CLTIME1, CLTIME2 and CLTIME3. Since the number of job
table signals in the exchange is a limited resource, avoid the concurrent
use of more than two job-table signals. See references [4] and [2].

To keep the central processor load as low as possible, be sure to make the
time intervals as long as possible. Do not use job table signals, if the wait-
ing time is very long, or if an interrupt or pause is needed in a job. In these
cases, put a signal in one of the time queues.

References

[1]

Plex-C Language Description
Procedures INTERVAL and JOBTABLE (page 138)
EN/LZB 101 1903 R2A
© Ericsson Telecom 1994

[2]

Software Reliability Handbook, Edition 4
Section 7.3, Periodic Signals (page 117)
EN/LZG 205 603 R4
© Ericsson Telecom 1996

[3]

Plex-C 1 (course book): Chapter 6, Block Interaction
EN/LZT 101 1279 R4B
© Ericsson Telecom 1996

[4]

Limitations in Signal/Event Sending (DR)
ETX 102 60-1207 Uen
© Ericsson Telecom 1996

203

Chapter 11

Time Supervision and Time
Measurement

Introduction

Time is a critical resource in AXE software. The algorithms in this chapter
monitor and measure the execution time of an application or the waiting
time for a system resource. This chapter relies on reference [1] as major
source of information.

Figure 11.1

Chapter Objectives

Concepts

In time supervision, the time to be monitored is known. In time measure-
ment, this time is unknown.

Use time supervision to check if a certain event occurs in a certain time
interval to initiate some action after a certain delay.

Examples

•

Time supervision is essential in CP-EMRP signalling. Here, the CP
SW unit can only wait for the return signal for a limited time. The CP
SW unit has to supervise this time.

•

Time supervision can set a device to a certain state for some time.

•

Time supervision allows to monitor, whether an exchange technician
replies to a prompt after some time.

•

Time measurement, on the other hand, helps to determine the conver-
sation time of a phone call.

Chapter Objectives

After completing this chapter, you are able to:

• Describe time supervision and its implementation methods

• Implement the Clock-Timer Method following the design rule

• Describe time measurement and its implementation method

Plex-C 2

204

Methods

Implement time supervision with one of these methods.

•

Clock-Timer

•

Indexed Linked Lists

Implement time measurement with this method.

•

Stop-Clock

Introduction to the Clock-Timer Method

Insert periodic signal CLTIME0 in the job table at regular intervals.

Receiving CLTIME0, step up an internal CLOCK.

CLOCK steps through the odd numbers only. See the end of this sec-
tion for the reason. When the clock has reached its greatest value, the
next step sets CLOCK to 1. Figure 11.2 shows an example for 16-bit
variable CLOCK.

Figure 11.2

Stepping CLOCK

If a file of records needs time supervision, each record has its own
TIMER.

−

If a record has no time supervision in progress, set TIMER=0.

−

If a record uses time supervision, TIMER holds the odd
CLOCK value when timeout shall take place.

Each time, the program steps CLOCK (+ 2), scan all TIMERs to find
records whose TIMER is equal to CLOCK. For each record found,
take timeout action directly.

START a time supervision simply be setting the record’s TIMER to
the CLOCK value corresponding to the desired supervision time.
STOP a time supervision at any time by setting the record’s TIMER
to 0.

65535

...

Time Supervision and Time Measurement

205

Efficient Implementation

Consider these points to keep the CP load of time supervision programs as
small as possible.

The CLOCK interval, that is, the interval between receiving
CLTIME0 has to be as large as possible, since scanning the TIMERs
takes CP time.

Optimise the scanning too. Keep the CP load as low as possible by
scanning a file of records with ASA instruction FESR. Use a FOR
FIRST loop ending with a GOTO. To compile FOR FIRST into
FESR, make sure TIMER is not an indexed or structured variable.

The time FESR scanning needs per record depends on the bit-length
of variables TIMER and CLOCK. Make sure to declare these varia-
bles as small as possible. The necessary bit-length depends on the
maximum waiting time required in the program.

Stepping CLOCK by 2

To make scanning the TIMERs fast and simple, the algorithm indicates
“no supervision” with one of the TIMER values. This value is 0 (zero) so
that clearing all supervisions at restart can easily be achieved by CLEAR-
marking the TIMER variable. Hence, CLOCK needs to skip TIMER value
0 (zero).

To make things simple, variable CLOCK skips all even values. If CLOCK
were to skip only value zero, IF-checks would be necessary to avoid zero
when stepping CLOCK. In addition, when setting a TIMER, the TIMER
value for a desired supervision time would depend on whether or not vari-
able CLOCK would overflow this time.

Example on Clock-Timer

Assume the following file of records, where Figure 11.3 shows the first 8
individuals, is supervised every second. Assume the program has just
stepped variable CLOCK to 1.

Figure 11.3

Variable TIMER in the first 8 records of a file

TIMER

CLOCK

Plex-C 2

206

•

In one second, CLOCK reaches the value 3, and record 7 reaches time-
out.

•

In three seconds, CLOCK reaches the value 7, and records 1 and 3
reach timeout.

Timeout Value

With Clock-Timer, this formula calculates the time-out value for TIMER.

•

timeout value = current clock-value + increment

where

•

increment = 2 * (desired supervision time / clock interval) + 2

Figure 11.4 translates these statements into Plex-C.

Figure 11.4

Setting variable TIMER

Example (cont’d)

The example from page 205 continues. Suppose record number 2 needs to
monitor an event after 20 seconds. Variable CCLOCK is currently 1. Now,
what is the value of TIMER?

SUPTIME = 20;

[unit: seconds]

ZCLOCKINTERVAL = 100;

[unit: centiseconds]

CINCREMENT = 2 * (20 * 100/100) + 2 = 42;
DEVP = 2;
DEVP:TIMER = 1 + 42 = 43;

Adding 2

How come the formula adds an additional 2 to the increment?

Most applications start supervisions at random with respect to the moment
the clock steps. Therefore, it is impossible to obtain exact supervision
times. In general, applications require that the supervision time is not
shorter than the desired time. Hence, it is safer to add an extra 2.

Consequence: the supervision is between the desired time and the desired
time plus one clock interval.

CINCREMENT = 2 * (SUPTIME * 100/ZCLOCKINTERVAL) + 2;

DEVP:TIMER = CCLOCK + CINCREMENT;

SUPTIME: supervision time in seconds

ZCLOCKINTERVAL: interval for stepping CLOCK in centiseconds

Time Supervision and Time Measurement

207

Not Adding 2

Some applications, however, require more precise and not “safe” time
supervision. For example, charging functions might prefer not to add an
extra time interval when supervising the length of a phone call. In these
cases it is suggested not to add 2, that is, follow this formula to calculate
CINCREMENT.

CINCREMENT = 2 * (SUPTIME * 100/ZCLOCKINTERVAL);

Supervision Accuracy

Note that Clock-Timer is not a precise algorithm. Section Adding 2 on
page 206 showed that the accuracy cannot be greater than the clock inter-
val. Furthermore, the method only reaches the desired supervision time,
when the division in the formula does not give a remainder.

To make the resulting delays more predictable to everybody reading the
program, ensure that supervision times * 100 are multiples of the clock
interval.

Clock-Timer Program

Please study the following, complete code example. It originates from ref-
erence [1]. Apart from the missing forlopp code, it is the same program as
in the design rule.

In this example, the program processes at most one timeout per scanning
phase. The timeout actions may include sending a signal which leads to
further buffered signalling.

Restarts

In the example, the restart subprogram clears all supervisions. See refer-
ence [1] for alternatives.

Please

Please do not panic when browsing the extensive program segment. The
code includes phase division, avoids sending more than 32 buffered sig-
nals and is a very positive example for good Plex-C programming. See
also reference [5] for a complete discussion of limitations in signal send-
ing.

However, it is not absolutely essential to understand all parts of the source
program.

Plex-C 2

208

Figure 11.5

Clock-Timer program, part 1(5)

DECLARE;

!
GLOBAL SYMBOLS
==============
!
GLOBAL NSYMB SUPTIME(#FF);

! SUPERVISION TIME IN SECONDS !

!
LOCAL SYMBOLS
=============
!
NSYMB ZCLOCKINTERVAL = 100;

! CLOCK INTERVAL IN CENTISECONDS !

NSYMB ZSCANLIMIT = 4000;

! ZSCANLIMIT + 1 = MAX. NO. OF !
! INDIVIDUALS SCANNED IN ONE PHASE!

NSYMB ZMAXCLSCAN0 = 32;

! MAX. NO. OF PHASES BEFORE !
! CONTINUEC (TO PREVENT POSSIBLE !
! B-LEVEL BUFFER CONGESTION AND !
! TO ALLOW EXECUTION AT C-LEVEL) !

NSYMB ZMAXCONTINUEC = 32;

! MAX. NO. OF CONTINUEC BEFORE !
! CONTINUED !
! (TO ALLOW EXECUTION AT D-LEVEL) !

NSYMB ZNO = 0;
NSYMB ZYES = 1;

!
RECORDS AND FILESIZES
=====================
!
RECORD DEVDATA;
VARIABLE TIMER

8 DS CLEAR;

END RECORD;
POINTER DEVP(DEVDATA);

!
COMMON STORED VARIABLES
=======================
!
VARIABLE CCLOCK

8 DS;

VARIABLE CCLOCKPERIODACTIVE

16 DS CLEAR;

! INDICATES UNFINISHED !
! SCANNING !

VARIABLE CCLSCAN0COUNTER

16 DS;

! NO. OF PHASES SINCE !
! LAST CONTINUEC !

VARIABLE CCONTINUECCOUNTER

16 DS;

! NO. OF CONTINUEC !
! SINCE LAST CONTINUED !

VARIABLE CINDNUMD

16 DS RELOAD;

VARIABLE COWNREF

16 DS;

!
TEMPORARY VARIABLES
===================
!
VARIABLE TDEVP;
VARIABLE TSTOPDEVP;

END DECLARE;

Time Supervision and Time Measurement

209

Figure 11.6

Clock-Timer program, part 2(5)

PROGRAM; PLEX;

!
START AND RESTART
=================
!

!
>STTOR>
!

ENTER STTOR WITH ... ;

!
SYMBOLIC START PHASE SPH7
AT SYSTEM RESTART (NOT AT SYSTEM START):
!

CCLOCK = 1;

! ENSURE THAT CCLOCK IS ODD. !

JOBTABLE INSERT CLTIME0

! START THE TIME SUP. ROUTINE!

INTERVAL IS ZCLOCKINTERVAL CS;

SEND STTORRY WITH ... ;
EXIT;

!
TIME SUPERVISION
================
!

!
>CLTIME0>
!

ENTER CLTIME0;
INTERVAL IS ZCLOCKINTERVAL CS;

!
IF SCANNING IS FINISHED FOR THE OLD CLOCK-VALUE, STEP THE CLOCK
AND START SCANNING WITH THE NEW CLOCK-VALUE:

THE FIRST IF-STATEMENT IS UNNECESSARY IF CINDNUMD IS CHECKED
(AS IN THIS EXAMPLE) AT CLSCAN0 ENTRY.
!

IF CINDNUMD > 0 THEN

IF CCLOCKPERIODACTIVE = ZNO THEN

CCLOCK = CCLOCK + 2;
DEVP = CINDNUMD - 1;
CCLOCKPERIODACTIVE = ZYES;
CCLSCAN0COUNTER = 1;
CCONTINUECCOUNTER = 0;
SEND CLSCAN0 REFERENCE COWNREF WITH

DEVP;

FI;

FI;
EXIT;

Plex-C 2

210

Figure 11.7

Clock-Timer program, part 3(5)

!
>CLSCAN0>
!

ENTER CLSCAN0 WITH

DEVP;

!
THE CODE FOR THE CASE DEVP >= CINDNUMD IS NECESSARY WHEN THE FILE
SUBJECT TO TIME SUPERVISION HAS AN ALTERABLE SIZE, SINCE A SIZE
ALTERATION EVENT MAY TAKE PLACE BETWEEN SCANNING PHASES.
THIS MAY HAPPEN EVEN FOR A B-LEVEL SCANNING (AS WITH CLSCAN0)
SINCE CONTINUEC AND CONTINUED ARE ALSO USED.
!

IF DEVP >= CINDNUMD THEN

IF CINDNUMD = 0 THEN

CCLOCKPERIODACTIVE = ZNO;
EXIT;

ELSE

DEVP = CINDNUMD - 1;

FI;

! SCAN PART OF THE FILE FOR FIRST TIMEOUT: !

IF DEVP > ZSCANLIMIT THEN

TSTOPDEVP = DEVP - ZSCANLIMIT;

ELSE

TSTOPDEVP = 0;

FI;
FOR FIRST DEVP FROM DEVP UNTIL TSTOPDEVP

WHERE DEVP:TIMER = CCLOCK GOTO TIMEOUT;

! ORDER NEW SCANNING PHASE IF NOT ALL THE FILE HAS BEEN SCANNED: !

IF TSTOPDEVP = 0 THEN

! DEVP IS UNDEFINED AFTER THE LOOP !

CCLOCKPERIODACTIVE = ZNO;

ELSE

DEVP = TSTOPDEVP - 1;

! DEVP IS UNDEFINED AFTER THE LOOP !

IF CCLSCAN0COUNTER < ZMAXCLSCAN0 THEN

CCLSCAN0COUNTER = CCLSCAN0COUNTER + 1;
SEND CLSCAN0 REFERENCE COWNREF WITH

DEVP;

ELSE

CCLSCAN0COUNTER = 1;
IF CCONTINUECCOUNTER < ZMAXCONTINUEC THEN

CCONTINUECCOUNTER = CCONTINUECCOUNTER + 1;
SEND CONTINUEC REFERENCE COWNREF WITH

DEVP;

ELSE

CCONTINUECCOUNTER = 0;
SEND CONTINUED REFERENCE COWNREF WITH

DEVP;

FI;

Time Supervision and Time Measurement

211

Figure 11.8

Clock-Timer program, part 4(5)

FI;
EXIT;

TIMEOUT)

! ORDER NEW SCANNING PHASE IF NOT ALL THE FILE HAS BEEN SCANNED: !

IF DEVP = 0 THEN

CCLOCKPERIODACTIVE = ZNO;

ELSE

TDEVP = DEVP - 1;

IF CCLSCAN0COUNTER < ZMAXCLSCAN0 THEN

CCLSCAN0COUNTER = CCLSCAN0COUNTER + 1;
SEND CLSCAN0 REFERENCE COWNREF WITH

TDEVP;

ELSE

CCLSCAN0COUNTER = 1;
IF CCONTINUECCOUNTER < ZMAXCONTINUEC THEN

CCONTINUECCOUNTER = CCONTINUECCOUNTER + 1;
SEND CONTINUEC REFERENCE COWNREF WITH

TDEVP;

ELSE

CCONTINUECCOUNTER = 0;
SEND CONTINUED REFERENCE COWNREF WITH

TDEVP;

FI;

! TAKE CARE OF TIMEOUT: !

DEVP:TIMER=0;

! SUPERVISION IS OVER FOR THIS IND. !

! HERE, TIMEOUT ACTIONS SHALL BE INSERTED !

EXIT;

Plex-C 2

212

Figure 11.9

Clock-Timer program, part 5(5)

!
>CONTINUEC>
!

ENTER CONTINUEC WITH
DEVP;
SEND CLSCAN0 REFERENCE COWNREF WITH
DEVP;
EXIT;

!
>CONTINUED>
!

ENTER CONTINUED WITH
DEVP;
SEND CLSCAN0 REFERENCE COWNREF WITH
DEVP;
EXIT;

END PROGRAM;

Time Supervision and Time Measurement

213

Indexed Linked Lists

This is the second method available to implement time supervision. Again,
the job table sends the periodic signal CLTIME0 to step an internal
CLOCK at regular intervals. As in the clock-timer method, the CLOCK
belongs to the supervision routine, and will overflow automatically. The
following steps describe this method.

Each CLOCK value has a separate linked list containing all records
which shall have timeout at this time.

CFIRST is an array variable with one element for each CLOCK
value. CFIRST contains the pointers to the beginning of the linked
lists for each CLOCK value. The index in array CFIRST corre-
sponds to the CLOCK value.

Figure 11.10

Data structure in Indexed Linked Lists

101

101

481

101

481

117

117

CFIRST (CCLOCK)

Index
CCLOCK

Double Linked Lists

etc.

Plex-C 2

214

Figure 11.10 shows elements 1 to 4 of array CFIRST. The array index is
also the value of CLOCK.

Note that this implementation uses the NIL-pointer value 0. Therefore, do
not use any records with number 0. This makes it possible to declare array
CFIRST as CLEAR variable and eliminates the need for a loop in the
restart subprogram.

Example

Suppose the program just stepped CLOCK to 0. The program repeats time
supervision every 10 milliseconds.

•

In 10 milliseconds, records 32, 101, 69 and 481 reach timeout.

•

In 30 milliseconds, records 8 and 13 reach timeout.

•

In 40 milliseconds, records 177, 22 and 1 reach timeout.

Each time the clock is stepped, the program processes the list for the
current clock-value. The programs remove the records from the
linked list and call the corresponding timeout action.

Comparison: Clock-Timer versus Linked Lists

•

Clock-Timer is simpler, as it does not require linking and removing
records into linked lists

•

Clock-Timer may give a higher CP load, since the algorithm scans all
records each time the CLOCK is stepped

•

Summary: prefer the Clock-Timer method, as long as the CP load is
low or moderate.

Please see reference [1] for further details.

Time Supervision and Time Measurement

215

Stop-Clock Method

This method implements time measurement, that is, determining the dura-
tion of an event in progress.

Again, the job table sends periodic signal CLTIME0 to step an internal
CLOCK belonging to the time measurement subprogram. Each user of
time measurement has its own start variable.

Start the measurement by setting the start variable to the clock-value.
When the measurement ends, calculate the length of the measured time
from the start variable and the current clock-value. Be sure to consider a
possible “round-stepping” of the clock.

The accuracy of the result is plus/minus one clock interval. Please see ref-
erence [1] for further details.

Chapter Summary

Remember these points from this chapter.

Figure 11.11

Summary

References

[1]

The Jobtable, Time Supervision, and Time Measurement (DR)
ETX 102 60-1192 Uen
© Ericsson Telecom 1996

[2]

Plex-C Language Description
EN/LZB 101 1903 R2A
© Ericsson Telecom 1994

[3]

Software Reliability Handbook, Edition 4
EN/LZG 205 603
© Ericsson Telecom 1996

[4]

Plex-C 1 (course book)
especially Chapter 6, Block Interaction, and 7, Call Routines
EN/LZT 101 1279 R4B
© Ericsson Telecom 1996

• The difference between time supervision and time measure-

ment.

• Two methods, Clock-Timer and Indexed Linked Lists, imple-

ment time supervision.

• One method, Stop-Clock, implements time measurement.

Plex-C 2

216

[5]

217

Chapter 12

Efficient Design

Introduction

This chapter presents various ways of improving Plex-C programs. The
goal is to create faster code which minimises the processor load.

Figure 12.1

Chapter Objectives

Concepts

AXE exchanges become more and more powerful, offer new services and
include new functions. The consequence is that the number of blocks, jobs,
signals and variables increases constantly. In spite of ever bigger and faster
processor hardware, the explosion in software prevents contemporary
exchanges from processing traffic faster than ten years ago.

Therefore, every designer should strive to keep the processor load as low
as possible. For more information see chapters Real Time in reference [3]
and Designing Capacity-Efficient Software in reference [1].

Definitions

Processor Load. The part of time the processor executes work on buffer
level C and higher. Thus, D-level jobs do not contribute to the processor
load. Unit: percent.

Processor load consists of idle load, traffic load and usage load.

Idle Load. Processor work which does not depend on traffic or external
activities. Example: job table scanning.

Traffic Load. Processor work which results from traffic handling, namely
calls, messages or handovers.

Usage Load. Processor work which results from operation and mainte-
nance activities during busy hours, namely command execution, data
dumps and traffic measurement printouts.

Chapter Objectives

After completing this chapter, you are able to:

• Describe methods of improving the CP capacity

• Declare data in a memory-efficient way

Plex-C 2

218

Processor Capacity. The number of tasks the processor executes per sec-
ond. Unit: number of instructions per second, or millions of instructions
per second (MIPS).

Efficient Data Design

Table 12.1 compares the access times for different types of variables, see
also reference

[1]

. Always give preference to temporary variables if the

program is time-critical.

Table 12.1

Typical access times per variable type

The table shows clearly which variables ensure fast access. Always use
temporary variables if the program permits.

ARRAYS. Indexed variables are effective when the program needs to
read or write a lot of data. Since the data is stored consecutively in the
memory, the ASA program can use fast instructions to read from and write
into the memory. Example: reading ten consecutive array elements takes
7.1

s instead of 9.8

s when using ASA read statement RSI instead of

RS.

BUFFER. BUFFER variables take the most CP time by far. Avoid
BUFFER variables as much as possible, except in file-oriented input/out-
put tasks and when sharing large quantities of data between different CP
SW units. See reference [1], section Dynamic Buffers, for more details.

APZ 211 11

APZ 212 11

Variable type

one

access

ten

accesses

one

access

ten

accesses

Temporary

0.16

0.2

Common DS

0.81

0.4

Structured

0.98

0.5

Record

0.98

0.6

Indexed

0.98

9.8/7.1

a. Read from Store Indexed (RSI)

0.6

6.0/3.6

b. Read from Store Indexed (RSI)

Indexed 2-dimensional

1.14

1.1

Dynamic buffer

6.75

66.0/15.5

c. Read Dynamic Buffer Indexed (RDBI)

2.3

23.0/5.3

d. Read Dynamic Buffer Indexed (RDBI)

Efficient Design

219

Improved Use of Memory

The contents of program store and data store grow rapidly. Even if mem-
ory is rather inexpensive, do not waste memory either. An ever-growing
data store can also take CP capacity to administer the memory.

Useful Hints

•

Record variables are most critical, since they take space in hundreds or
thousands of records. So, verify that all record variables are really nec-
essary.

•

Investigate if it is possible to transfer some record variables into com-
mon stored or temporary variables.

•

Avoid symbol variables in records. Investigate if it is possible to
replace a symbol variable with a field variable which may be smaller,
or merge several symbol variables into one.

•

Validate all RELOAD variables. Make sure they are not set in the
restart subprogram, otherwise there is no need to declare them as
RELOAD.

•

With linked lists, investigate if the program really needs a double-
linked list or if a single-linked list can do the job too.

Efficient Program Design

Signals

•

Avoid data value + in signal sending statements. The receiving SW
unit should decide whether or not all the signal data are relevant.

•

Try to keep the signal data words in the same CP registers by keeping
the place and order of the signal data in signal reception and signal
sending statements. Add new signal data at the end of the signal data
words. This strategy saves a few MFR (Move From Register) state-
ments.

•

Reduce the number of IFs, tests and cases after receiving a signal.
Limit the number of various conditions and situations, and combine
them into certain states. Consider the example in Figure 12.2.

Plex-C 2

220

Figure 12.2

Optimising tests after signal receptions

Focus on the Normal Case

The normal case refers to the most frequently executed program code.
Find out the normal case in each application before writing or optimising
the code. Make sure that the number of checks (IF, CASE) and jumps
(GOTO) is minimal for normal cases, even if this increases the CP load in
all other, less frequent cases.

If possible, give preference to CASE statements over nested IF statements.

Iterations

Loops, or iterations, are crucial to efficient design. Since the exchange
repeats the statements in the loop several times, inefficient programs sig-
nificantly increase the CP load.

Plex-C includes three loop statements, ON, FOR FIRST and FOR ALL.
Under certain conditions, FOR FIRST and FOR ALL compile to the ASA
statement FESR. See reference [4] for complete details.

As reference [1], section Loops, shows, FOR ALL is equally fast as ON, if
the program does not meet the conditions for FESR.

The shorter the loop variable, the more efficient is FESR. This is because
the instruction compares 16 bits (32 bits for APZ 212) at a time. If the var-
iable length is 4 bits, it can investigate 4 (8) variables at a time. If the
number of turns in the loop is less than 5, or if every individual needs to be

ENTER SIGNAL WITH D1, D2, D3;

D1 = A THEN

D2 = B THEN

CASE D3 IS

WHEN 1 DO ...

WHEN 2 DO ...

OTHERWISE DO ...;

ESAC;

FI;

ENTER SIGNAL WITH STATE;

CASE STATE IS

WHEN STATE1 DO ...;

STATE = STATE10;

WHEN STATE2 DO ...;

STATE = STATE20;

OTHERWISE

DO ...;

STATE = STATE30;

ESAC;

BAD

CODE

GOOD
CODE

Efficient Design

221

treated, ON is as good as FOR ALL, even if FOR ALL generates an FESR.
Please consider negative and positive examples in Figure 12.3.

Figure 12.3

Optimising a FOR FIRST loop

If the loop examines 1000 16-bit variables, the first loop in Figure 12.3
takes about 3.2 ms, and the second one takes 0.5 ms (for APZ 211 11).
Moreover, the first solution may require a phase division, which may
imply problems from variable interference, and makes the design more
complex.

Subroutines

Use subroutines such as statement blocks to save program store, if the sev-
eral segments of a program require the same routine. However, to execute
subroutines, jumps to and from the subroutine are necessary, which gener-
ates additional load.

Furthermore, similar routines can sometimes be merged into subroutines
that become general, which means that they contain IF statements in order
to execute code differently depending on where they are called from. This
also increases the CP load.

Using a large number of subroutines may also make the program hard to
follow and understand.

FOR FIRST BLOCKINDEX FROM MAXINDEX

WHERE SOMESTATE (BLOCKINDEX) = BLOC

GOTO FOUND;

%L17)

JEC

WR5,0,%L18;

SCC

WR5-1;

MFR

IR-WR5;

AR0-SOMESTATE;

JEC

AR0,1,%L%FOUND;

JLN

%L17;

%L18)

...

%L%FOUND)

FOR FIRST REP FROM START - 1

WHERE MSTATE = IDLE

GOTO RESEIZED;

LCC

PR1-0;

PR0-START;

LCC

CR-9;

FESR MSTATE, %L0;

JLN

%L1;

%L0)

MFR

WR6-PR0;

JLN

RESEIZED;

%L1)

...

SLOW

CODE

FAST

CODE

Plex-C 2

222

Chapter Summary

Remember these points from this chapter.

Figure 12.4

Summary

References

[1]

[2]

[3]

[4]

• Efficient data and program design allows to reduce the CP load

of AXE software.

• Save space in the data store and reduce the risk for variable

interference by using simple, possibly temporary, variables
whenever possible.

• Large numbers of IF statements, jumps and statement blocks

may be an indicator for inefficient code.

• Be careful when using dynamic buffers or iteration statements.

Consider more efficient alternatives while programming.

223

Chapter 13

CP-RP/EMRP Interaction

Introduction

Communication between CP and RP SW units is essential for all AXE
blocks having APT hardware or I/O devices. This chapter shows how to
program CP-RP interaction in CP SW units and attempts to summarise the
various types of regional processors and their functions.

Figure 13.1

Chapter Objectives

Regional Processor Subsystem

The regional processor subsystem (RPS) stores and executes the regional
software associated with the switching system (APT) and the control sys-
tem (APZ). This software handles simple and routine tasks such as scan-
ning hardware. See also section Regional Processor Subsystem in
reference [1].

This subsystem consists of a number of regional processors (RP and RPD),
extension module regional processors (EMRP and EMRPD) and signal
terminals, namely signalling terminal central (STC) and signalling termi-
nal remote (STR).

Regional Processors

The duplicated regional processor bus (RPB) connects the RPs to the CPs.
Each RPB supports up to 32 RPs. The CP, namely APZ 212, can handle up
to 32 RPBs.

The RPs control the hardware which is organised in a number of extension
modules (EMs) which are individually scanned by an RP. The EM, being
the smallest handling unit in the system, includes a number of hardware
units, that is, devices or switches. See also Figure 13.2.

Chapter Objectives

After completing this chapter, you are able to:

• Briefly describe the functions in RP/EMRP

• Describe the interwork between CP and RP/EMRP

• Write Plex-C code for sending and receiving RP signals

Plex-C 2

224

Figure 13.2

AXE processor hierarchy

Normally two RPs, known as an RP pair, together control up to 16 EMs.
Each RP of the pair controls half of the connected EMs. If a fault occurs in
one of the RPs, the other RP takes over control of all connected EMs.

The EM bus (EMB) connects the EMs to the RPs.

Software Functions of RP

The RP software has these responsibilities concerning the hardware units
in the EMs.

•

Operate the hardware for a certain type of device. CP-RP signals acti-
vate such tasks in the RP software.

•

Communicate with the CP. The RP software checks if the CP sent any
signals to the RP, forwards the information to the correct hardware
unit, and responds to the CP.

•

Initiate scanning programs at regular intervals to detect changes in the
hardware. See Figure 13.3.

EM-0

CP-A

EM-1

MAU

EM-15

Extension

Modules

Regional

Processors

Central Processor

with Maintenance

Unit (MAU)

CP-B

EMB

RPB

Central Processor

MAU

Maintenance Unix

Extension Module

Regional Processor

EMB

Extension Module Bus

RPB

Regional Processor

CP-RP/EMRP Interaction

225

Figure 13.3

Software Functions of RP

Types of Regional Processors

RP1. RP software controls the APT application hardware and the I/O
devices and runs on regional processors. The early days of AXE knew
only one type of regional processor, the RP1, that handled all communica-
tion with the APT hardware and I/O devices. The RP1 was a rather primi-
tive processor, storing all of its programs in PROM memory.
Programming language: ASA 210R.

EMRP. With the introduction of the digital subscriber stage, the regional
processor subsystem offered a new processor type, the extension module
regional processor (EMRP). The EMRP controls the subscriber stage
equipment. The majority of the EMRP software resides in random-access
memory (RAM).
CPU: Motorola 6809. Programming language: Plex-M, a high-level, 8-bit
dialect of Plex-C.

RP2. The RP1 was rather primitive and soon replaced by the more
advanced RP2. The advantages of the RP2 include the use of RAM,
smaller size and a much better operating system.
CPU: Motorola 6809. Programming language: ASA 21R, a more efficient
version of ASA 210R.

SP. I/O communication requires higher processor capacity and needed a
special processor, the support processor (SP). The SP is part of the support
processor subsystem (SPS) and the IOG-11. The SP uses RAM memory.

Hardware

Operation of

Hardware

Changes in

Hardware

Regional
Software

Central

Software

To other Function Blocks

Data

Telephony Signals

Data

in RP

in CP

Plex-C 2

226

CPU: APN 167, a processor based on Motorola 68010 or Motorola 68030.
Programming language: ERIPASCAL, a real-time dialect of the high-level
language PASCAL.

RPD. New applications, such as ISDN and mobile telephony, required
new regional processors with a much higher capacity. The regional proces-
sor digital (RPD) handles large complex programs and makes it possible to
relocate tasks from the CP to the RPD to optimise the CP capacity.
CPU: Motorola 68020, programming languages: C or C++.

EMRPD. The extension module regional processor digital (EMRPD) has
a higher capacity than the EMRP and handles large complex programs.
The EMRPD appears in the subscriber switch subsystem (SSS). As for
EMRPs, the EMRP bus (EMRPB) connects EMRPDs to the signalling ter-
minals remote (STR). An internal EMRP bus connects the switching hard-
ware directly to its EMRP, this is not visible in Figure 13.5.
CPU: Motorola 68020, programming languages: C or C++.

Figure 13.4

Units connected to the RP bus

RPG. This is the latest regional processor serving hardware units in the
group switch subsystem (GSS). The RPG offers even higher capacity than

EMRPD

CP-A

CP-B

EMRP-31

EMRP-30

EMRPB

CCS7

Control

Signalling

Link

EMRP-1

EMRP-0

STR

STC

EM 15

RPBC

RPA

STR

STC

EM 0

RPD

RPB

RPBC

EMRP-0

CP-RP/EMRP Interaction

227

the RPD. Figure 13.4 does not show the RPG.
CPU: Motorola 68060, programming languages C or C++.

For more details, see reference [1].

The remainder of this chapter discusses the RP2 and EMRP units only.

Extension and Control Modules

An extension module (EM) is usually a magazine containing a number of
printed circuit boards. It is the smallest hardware unit which can be added
or removed in the exchange.

There is one regional software program controlling each EM. Hardware
and software units belong to the same function block, since all equipment
in the EM is of the same type. Each EM number has a one-to-one corre-
spondence to one regional program and its data. Control module (CM) is
name for a regional program controlling one EM.

So, usually one CM controls one EM, see Figure 13.5. Exceptions include
time-switch modules (TSMs) where one CM supervises two EMs.

Figure 13.5

One CM controls one EM

CM 0

CM 1

CM n

EM n

EM 0

EM 1

Plex-C 2

228

The design rule in reference [3] summarises EM and CM in this way. An
EM is

•

a magazine

•

an extension unit

•

an exclusion unit

•

a blocking unit,

while a CM is

•

a regional software unit.

The exchange technician may block and deblock EMs, like most other
hardware. The operating system can start and restart CMs, like most other
software units. To start a CM, insert a periodic signal in the job table.

RP2 Functions

The RP2 controls most types of application hardware, excluding the sub-
scriber switch and, in the future, the group switch. AXE exchanges have
up to 1,024 RP2s. Figure 13.6, a repeat of Figure 13.2, shows the connec-
tions between the RP2 and its partners.

Figure 13.6

The RP2 hardware structure

Each EM has APT devices of one type, for example, 32 BT devices. Dif-
ferent EMs may contain different device types.

EM-0

CP-A

EM-1

MAU

EM-15

Extension

Modules

Regional

Processors

Central Processor

with Maintenance

Unit (MAU)

CP-B

EMB

RPB

Central Processor

MAU

Maintenance Unix

Extension Module

Regional Processor

EMB

Extension Module Bus

RPB

Regional processor bus

CP-RP/EMRP Interaction

229

RP2 Software

Receiving CP-RP signals has higher priority than scanning the hardware
units. The operating system REX (regional executive program) adminis-
ters the work of the RP2. REX determines which program is running.

The RP2 execution splits into primary intervals of 5 ms. During this inter-
val, the control module once scans all devices in the EM and processes all
incoming CP-RP signals. These tasks usually take less time than 5 ms. The
remaining time in the primary interval is devoted to special maintenance
programs, MRP, which perform a number of different tests on the RP.

Figure 13.7 describes the RP operating mode during a primary interval. If
no CP signal is received, the software scans the devices in the EMs only.
The software scans the devices in the EMs in consecutive order beginning
with EM15 and ending with EM0. After scanning each EM, the operating
system, REX, takes over and determines which application program to
start next.

Figure 13.7

RP2 job execution during a primary interval

Figure 13.7 shows a CP-RP signal arriving for CM/EM6 while scanning
CM/EM13. The control system immediately interrupts the application pro-
gram for CM/EM13, and a microprogram stores the CP-RP signal data in
the RP memory. Then, the RP software resumes scanning of CM/EM13.

After the scanning of CM/EM13 has terminated, the operating system,
REX, takes control as usual. REX starts the application program for the
CP-RP signal. When this program finishes, REX calls the application pro-
gram of the next CM/EM to be scanned, CM/EM12.

If there is time left in the primary interval after scanning all CM/EMs,
REX calls the MRP programs. MRP programs routinely test the RP. As
Figure 13.7 shows, MRP programs execute in short sequences. After each
sequence, the control returns to REX to see if there are any CP-RP signals
to process, or if the primary interval is over. If there are no waiting CP-RP

REX

CM15

CM14

CM13

CM6

CM12

CM0

MRP

CM15

CP-RP signal

to CM6

Time

0 ms

5 ms

Plex-C 2

230

signals, and there is still time left, MRP continues for a short sequence.
After the primary interval, REX starts all over scanning CM/EM15.

If the primary interval is over before all CM/EMs have been scanned, the
next interval does not start. The operating system delays the next primary
interval until all CMs are complete. However, if the primary interval is
exceeded several times in a row, the RP software notifies the CP software.

EMRP Functions

In addition to its use in the subscriber switch subsystem (SSS), EMRPs
control functions in a number of other AXE subsystems, such as input-out-
put, ISDN and mobile telephony. However, this section concentrates on the
EMRP in the SSS.

As for RPs, the EMRPs control telephony hardware and execute orders
initiated by CP-EMRP signals. A single or duplicated EMRP controls the
equipment in a single EM, also known as line switch module (LSM) in an
extension module group (EMG) which constitutes a subscriber stage.

An LSM includes equipment for connecting up to 128 subscribers. An
EMG contains a maximum of 16 LSMs giving a total connection capacity
of 2048 per EMG. The EMRP is mounted on the EM, that is LSM, it con-
trols. There are up to 32 EMRPs in each LMG. See Figure 13.8.

CP-RP/EMRP Interaction

231

Figure 13.8

The EMRP in the subscriber switch

For duplicated EMRPs, one of the two processors takes care of all the
work, while its twin is stopped.

Simple microprocessors known as device processors (DP) monitor the
telephony devices in the LSMs. The DPs send a signal to the EMRP when
an event occurs in the telephony device, and the DPs receive orders from
the EMRP to operate the telephony device.

Programming the EMRP in Plex-M is very similar to programming the CP
in Plex-C. For instance, Plex-M uses ENTER and SEND statements for
unit internal and external signal transmission.

CP-RP Unit Interaction

Sending a signal to an RP SW unit, the CP sends the RP and CM/EM num-
bers on the RP bus together with the other signal data. The RP picks up the
RP and CM/EM numbers to activate the right CM/EM.

LSM

EMRP

DEVCB

EMRPB

LSM

EMRP

DEVCB

LSM

EMRP

DEVCB

EMRPB-A

EMRPB-B

Plex-C 2

232

Figure 13.9

Declarations in CP SW unit CSR2U

Hardware-owning blocks define a distributed RP table in their CP SW
unit. Figure 13.9 shows the declaration of the distributed RP table in unit
CSR2U. The table consists of a file of records ADDRDATA, one record
for each EM. Record variable DEVADDR contains the number of the RP
in bits 0 to 11 and the EM number in bits 12 to 15.

Figure 13.10

Sending a CP-RP signal

In Figure 13.10, CSR2U sends signal SENDFSRPCS to CSR2R. Variable
DEVADDR contains the number of the RP and the EM/CM, while DEVP
contains the number of the CSR device.

Figure 13.11 shows sample hardware structure and distributed RP table in
blocks CSR2 and ET.

!-------------------- !

VARIABLES PER EM

!-------------------- !

RECORD ADDRDATA;

VARIABLE DEVADDR 16 DS RELOAD; !RP AND EM ADDRESS!

END RECORD;

POINTER ADDRP (ADDRDATA);

STRUCTURE DEVADDR

1 RPADDR 12,

1 EMADDR 4;

SEND SENDFSRPCS REFERENCE DEVADDR WITH

DEVP,

! DEVICE NUMBER

OTSIGVAL; ! VALUE OF DATA IN OT SIGNAL !

EXIT;

CP-RP/EMRP Interaction

233

Figure 13.11

Hardware structure and distributed RP tables

In this example, six EMs contain the telephony devices for blocks ET and
CSR2. Each EM includes 32 devices. The numbering of the devices is con-
secutive: RP 49 controls EM 0 with devices ET-0 to ET-31, EM 1 with
devices ET-32 to ET-63, and EM2 with devices ET-64 to ET-95.

The CP SW units contain the distributed RP tables. There is one entry for
each EM/CM. In the Plex programs, the file of records ADDRDATA with

CSR 64-95

RP 46

EM2

File DEVDATA

CSR 32-63

EM1

CSR 0-31

EM0

RP 47

ET 64-95

RP 48

EM2

ET 32-63

EM1

ET 0-31

EM0

RP 49

CP-B

CP-A

0-31

32-63

64-95

Device

Distributed RP table

CP SW Unit CSR2U

File DEVDATA

0-31

32-63

64-95

Device

Distributed RP table

CP SW Unit ETU

Plex-C 2

234

variable DEVADDR implements this table. The file contains one record
for each EM/CM.

It is easy to find the number of an EM for a given device. The EM number
is the integer portion resulting from the division of device number and
total number of devices per EM. Consider this code for block ET.

Figure 13.12

Calculating the EM number

In Figure 13.12, pointer variable DEVP contains device number 42. In this
block, each EM includes 32 devices. Hence, pointer variable ADDRP
points to the EM number DEVP/32 = 1.

Exchange technicians enter command EXEMI to build up the ADDR-
DATA records, in other words, the distributed RP table, in all hardware-
owning blocks. The following example defines the third entry for the dis-
tributed RP table in block ET.

Figure 13.13

Defining the distributed RP table

More details are available in a design rule, see reference [6]. In particular,
the design rule lists all signals that a device block with RP-controlled hard-
ware needs to receive.

Code Summary

Figure 13.14 contains a code excerpt from CP SW unit CSR2U. The figure
repeats the declaration and use of variable DEVADDR in one code exam-
ple.

DEVP = 42;

ADDRP = DEVP/32;

EXEMI:RP=49,RPT=48,EM=2,EQM=ET-64&&-95;

CP-RP/EMRP Interaction

235

Figure 13.14

Addressing RP software in unit CSR2U

Note that the FILESIZE statement in the declare sector ensures that the
number of device records corresponds to the number of ADDRESSDATA
records at all times. Reference [2] discusses this statement in detail.

DOCUMENT CSR2UPROGRAM;

DECLARE;

NSYMB ZNOOFDEVINEM = 4;

!NUMBER OF DEVICES IN EM!

RECORD DEVICEDATA;

!ONE RECORD PER DEVICE!

END RECORD;

POINTER DEVP(DEVICEDATA);

RECORD ADDRESSDATA;

!ONE RECORD PER EM!

VARIABLE DEVADDR 16 DS RELOAD;

!RP AND EM ADDRESS!

END RECORD;

POINTER ADDRP(ADDRESSDATA);

FILESIZE OF ADDRESSDATA = (FILESIZE OF DEVICEDATA)/ZNOOFDEVINEM;

STRUCTURE DEVADDR

1 RPADDR 12,

1 EMADDR 4;

END DECLARE;

PROGRAM; PLEX;

SEND SENDFSRPCS REFERENCE DEVADDR WITH

DEVP,

!DEVICE NUMBER!

OTSIGVAL;

!VALUE OF DATA IN OT SIGNAL!

EXIT;

END PROGRAM;

END DOCUMENT;

Plex-C 2

236

CP-EMRP Unit Interaction

Communication with EMRP SW units requires a distributed RP table too.
However, EMRP-controlled EMs normally contain more than one type of
telephony device. Therefore, the EM number does not suffice to address
the EMRP program to be started.

To get to the appropriate EMRP program, the address consists of two
parts: the EM number and the control module extension (CME) number.
Thus, the complete address consists of two 16-bit words. Figure 13.15
shows parts of a distributed RP table for sample block KR2.

Figure 13.15

The distributed RP table for EMRP communication

Note that the actual size of subvariables, e.g. RP-address, may vary
depending on the subsystem. More important is that the size of variable
DEVADDR now consists of 32 bits. Otherwise, addressing EMRP soft-
ware follows the same principles as addressing RP software.

Exchange technicians load the distributed RP tables with command
EXEEI. This command generates signal EMINFO, which carries the data
to be stored in the table. Each CP SW unit with EMRP communication has
to accept this signal. For further information, please study reference [7].

Code Summary

Figure 13.16 contains a code excerpt from CP SW unit KR2U. The figure
presents the declaration and use of variable DEVADDR in a code example.
Note that the structure of variable DEVADDR, namely the size of its sub-
variables, depends on the source system.

address

B E

RP-address

9 7

address

B E

RP-address

address

B E

RP-address

CME

Unit:

0-7

8-15

16-23

Data Store

CP-RP/EMRP Interaction

237

Figure 13.16

Addressing RP software in unit CSR2U

Again, the FILESIZE statement establishes a fixed relationship between
the file size of records DEVICEDATA and ADDRESSDATA. If the code
assigns a certain value to pointer DEVP, pointer ADDRP automatically
receives a value corresponding to the relationship. In the example, the
code explicitly assigns 37 to pointer DEVP, and implicitly sets ADDRP to
37/8 = 4. See reference [2].

Chapter Summary

Remember these points from this chapter.

DOCUMENT KR2UPROGRAM;

DECLARE;

NSYMB ZNOOFDEVINEM = 8;

!NUMBER OF DEVICES IN EM!

RECORD DEVICEDATA;

!ONE RECORD PER DEVICE!

END RECORD;

POINTER DEVP(DEVICEDATA);

RECORD ADDRESSDATA;

!ONE RECORD PER EM!

VARIABLE DEVADDR 32 DS RELOAD;

!RP AND EM ADDRESS!

END RECORD;

POINTER ADDRP(ADDRESSDATA);

FILESIZE OF ADDRESSDATA = (FILESIZE OF DEVICEDATA)/ZNOOFDEVINEM;

STRUCTURE DEVADDR

1 RPCM

16,

10,

CME

16;

END DECLARE;

PROGRAM; PLEX;

DEVP= 37;

SEND TIMEKR REFERENCE ADDRP:DEVADDR WITH

DEVP;

!DEVICE NUMBER!

EXIT;

END PROGRAM;

END DOCUMENT;

Plex-C 2

238

Figure 13.17

Summary

References

[1]

AXE 10 Survey (course book)
EN/LZT 101 1513 R2A
Ericsson Telecom 1995

[2]

Plex-C Language Description
especially Chapter 4, Declaration of Number of Devices per CM
EN/LZB 101 1903 R2A
© Ericsson Telecom 1994

[3]

[4]

[5]

[6]

[7]

[8]

[9]

• EM is a hardware concept and CM is a software concept.

• RP software covers several tasks during a primary interval.

• Addressing RP and EMRP software units when sending CP-RP

signals.

239

Chapter 14

Exercises

Exercise 1: Design Rules

240

Exercise 2: Block Type and Type Extension

242

Plex-C 2

240

Exercise 1: Design Rules

This exercise should follow Chapter 1, Design Essentials.

Open APStools and start DRtool. The text in the icon is Design Rules. You
may also open DRtool by typing “drtool” in a shell tool.

Find the following design rules and answer the questions below.

Design rule:

Use of Block Types in AXE.

Question:

What is the document number of the design rule?

Answer:

_______________________________________.

Design rule:

Execution Time Limits.

Question:

What is the document number of the design rule?

Answer:

_______________________________________.

Design rule:

ETX 102 60-1042 Uen

Question:

What is the title of the design rule?

Answer:

_______________________________________.

Design rule:

ETX 102 60-1030 Uen

Question:

What is the title of the design rule?

Answer:

_______________________________________.

Question:

Fetch the document to your UNIX directory. Which
file name does DRtool suggest?

Answer:

_______________________________________.

Hint:

This file name is not very useful. Change the UNIX
file name so that it ends on .script. That way, dou-
ble-clicking on the file icon in the file manager
automatically starts the right editor, EDMLtool.

Open the document in EDMLtool and take a closer look at it.

Find all design rules that start with the word “command” in the title.

Question:

How many suitable documents are there?

Answer:

_______________________________________.

Exercises

241

Find all design rules that include the word “forlopp” in the title.

Question:

How many suitable documents are there?

Answer:

_______________________________________.

Select node OPERATION & MAINTENANCE in the DRtool tree

structure.

Question:

How many design rules contain the variable name
BLSTATE?

Answer:

_______________________________________.

Plex-C 2

242

Exercise 2: Block Type and Type Extension

This exercise should follow Chapter 4, CP-CP Unit Interaction.

Use DRtool to find the design rules concerning the use of block

types and block type extensions in AXE. Make a printout and

answer the following questions.

The function block KR is to have the following characteristics:

BCCOMREC, BCEXTREC, BCLOCSTART, BCRPEMCONT

BCAPT, BCAPTHW, BCINCOM, BCKR, BCROUTE,
BCSIGN, BCCRCS, BCTELDEV

One of the characteristics listed cannot be used in the KR pro-

gram. Using the design rules, decide which property should

not be included.

Answer:

_______________________________________.

Calculate the block type and the block type extension values

for the block KR.

Block type:

_______________________________________.

Block type extension:___________________________________.

The function block LI has the block type

BTLI = #9403

Does LI have the block characteristic “subscriber line“?

Answer:

_______________________________________.

1. In real life, block KR would not include command handling. However, this is not
the answer to the question in this exercise.

243

Chapter 15

Mini Project

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

Structure of block SELECT . . . . . . . . . . . . . . . . . . . . . . . . . 256

Structure of block DEVICE . . . . . . . . . . . . . . . . . . . . . . . . . 256

Function Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Exercise Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Input Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Exercise Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

Exercise Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Task 1 Declaring variables. . . . . . . . . . . . . . . . Chapter 3 261

Task 2 Block Types and Type Extensions . . . . Chapter 4 261

Task 3 Command Reception and Analysis . . . Chapter 5 261

Task 4 Printout DEVICE STATE SURVEY . . . . Chapter 6 261

Task 5 Finding an idle device record . . . . . . . . Chapter 6 261

Task 6 Start/Restart subprograms . . . . . . . . . . Chapter 7 261

Task 7 Level Change . . . . . . . . . . . . . . . . . . . . Chapter 8 263

Task 8 Size Alteration Events . . . . . . . . . . . . . Chapter 9 263

Task 9 Phase Division and Time Superv. . Chapters 8,11 264

Block Description - SELECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

Block Description - DEVICE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Command Description - EXDSC . . . . . . . . . . . . . . . . . . . . . . . . . 276

Printout Description - Device State Survey . . . . . . . . . . . . . . . . . 279

Signal Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

Plex-C 2

244

Introduction

This function produces a printout of device state information.

The function includes two blocks, SELECT and DEVICE.

Block SELECT receives the command, analyses the command parameter
and generates the printout.

Block DEVICE contains a file of device records and uses an idle linked
list.

Structure of block SELECT

This block contains software only, namely CP SW unit SELECTU. The
program has the following segments.

•

Start/Restart

•

Command Reception

•

Command Parameter Analysis

•

Printout of Data

Structure of block DEVICE

This block consists of hardware and software. The central software is in
CP SW unit DEVICEU. The program has the following segments.

•

Start/Restart

•

Size Alteration

•

Selecting an idle device

•

Counting the number of devices per state

Mini Project

245

Function Flowchart

The following two pages illustrate the behaviour of SELECT and
DEVICE. Note that these flowcharts do not follow all the syntax rules for
flowcharts and reflect the program flow only in a condensed format.

Figure 15.1

Function Flowchart, part 1(2)

Plex-C 2

246

Figure 15.2

Function Flowchart, part 2(2)

Mini Project

247

Exercise Overview

For this mini project, students have to write four documents:

•

Source Parameter List (SPL), one for each CP SW unit

•

Source Program Information (SPI), one for each CP SW unit

Input Documentation

This chapter includes printouts of the following input documents for the
mini project.

•

Block Descriptions (BD)

−

1551-CNT 216 9992 Uen

Block SELECT

−

1551-CNT 216 9991 Uen

Block DEVICE

•

Command Description (COD)

−

1/190 82-CNT 216 9992 Uen

Exchange Data Device
State, Change

•

Printout Description (POD)

−

1/190 83-CNT 216 9992 Uen

Device State Survey

•

Specific Signals (SD)

−

998/155 14-APT 210

Signal RSTATENUM

−

999/155 14-APT 210

Signal RSTATENUMR

−

997/155 14-APT 210

Signal NODEVICE

•

Generic Signals (SD)

The programs use generic signals for start/restart and size alteration sub-
programs. The block descriptions list the relevant signal names. The signal
descriptions are available in this book, see Chapter 7, Software Recovery,
and Chapter 9, Size Alteration.

Plex-C 2

248

Exercise Layout

Tackle the mini project step-by-step. The work is divided into tasks which
the students should implement after attending the corresponding theory
included in this book. Background information is also available in the
Software Reliability Handbook and all applicable Design Rules.

•

Task 1

Declaring variables

Chapter 3

•

Task 2

Block Types and Type Extensions

Chapter 4

•

Task 3

Command Reception and Analysis

Chapter 5

•

Task 4

Printout DEVICE STATE SURVEY

Chapter 6

•

Task 5

Finding an idle device record

Chapter 6

•

Task 6

Start/Restart subprograms

Chapter 7

•

Task 7

Phase Division and Level Change

Chapter 8

•

Task 8

Size Alteration Events

Chapter 9

•

Task 9

Phase Division and Time Superv.

Chapters 8,11

Mini Project

249

Exercise Description

Task 1

Declaring variables

Chapter 3

This task affects both blocks. Declare all variables and symbols in the SPIs
and define the global symbols in the SPLs. Read the following input docu-
ments:

•

Command Description

•

Printout Description

•

Block Descriptions

•

Signal Descriptions: RSTATENUM, RSTATENUMR

and

NODEVICE

Task 2

Block Types and Type Extensions

Chapter 4

This task affects both blocks. Define the block characteristics, block types
and block type extensions in SPIs and SPLs. The block descriptions pro-
vide useful input information.

Task 3

Command Reception and Analysis

Chapter 5

This task affects block SELECT only. Implement command reception,
check if the command is busy, fetch the command parameter, analyse its
value and print an error message if any faults occur. The command
description and the block description for block SELECT provide useful
input information.

Task 4

Printout DEVICE STATE SURVEY

Chapter 6

This task affects block SELECT only. Receive signals RSTATENUMR
and NODEVICE. Then generate result printout DEVICE STATE SUR-
VEY, release the I/O device, set the command to idle and exit. The printout
description and the block description for block SELECT provide useful
input information.

Task 5

Finding an idle device record

Chapter 6

This task affects block DEVICE only. Receive signal RSTATENUM and
check if the idle linked list is empty. If so, answer with return signal
NODEVICE. Otherwise seize an idle device from the beginning of the idle
linked list and answer with return signal RSTATENUMR. The signal
descriptions and the block description for block DEVICE provide useful
input information.

Task 6

Start/Restart subprograms

Chapter 7

This task affects both blocks. Implement the start/restart subprograms in
both SPIs and update the SPLs. The STTOR/STTORRY signal descrip-
tions and the block descriptions provide useful input information.

Plex-C 2

250

Figure 15.3 and Figure 15.4 contain a small flowchart for the start/restart
subprogram in CP SW unit DEVICU. The flowchart is not complete, so
follow the hints in this book, the block descriptions, the design rules and
some common sense (smile) when writing this code.

Figure 15.3

Start/restart subprogram in DEVICEU

The second part of this flowchart is in Figure 15.4.

STTOR
[APZ
Start signal at
start/restart

Restart phase

SPH1DEVICE

Load own
block
reference

STTORRY
[APZ
Achnowledgement
of start signal

SPH3DEVICE

Restart
case

start
or
reload

initialize
global
and
blocking
states
of devices

other

SPH4DEVICE

StartRestart10
[P.3

Mini Project

251

Figure 15.4

Start/restart subprogram in DEVICEU

Task 7

Level Change

Chapter 8

This task affects both blocks. In block DEVICE, check the level at which
signal RSTATENUM operates. Does the level correspond to the general
purpose of this block? Likewise, check the level at which signals NODE-
VICE and RSTATENUMR arrive in block SELECT. Then implement level
change where necessary.

Task 8

Size Alteration Events

Chapter 9

This task affects block DEVICE only. Follow the theory in this book and
the design rules, when implementing size alteration in the SPI. The block
description for block DEVICE provides useful input information too.

StartRestart10

Restart case

Reload

BLSTATE = 0

Generate
idle linked list

Initialise
state counters

STTORRY
[APZ
Achnowledgement
of start signal

Yes

Mark state of
device idle

Small or large
system restart

Mark device
not blocked
for test and
not automatically
blocked

BLSTATE = 0

Mark state
of device
blocked

Yes

Mark state
of device
idle

Start

[P.2

Plex-C 2

252

Task 9

Phase Division and Time Superv. Chapters 8,11

This task affects block DEVICE only. Follow the theory in this book and
the design rules when implementing time supervision in the SPI. Use the
CLOCK-TIMER method for this assignment. Read the block description
for DEVICE to find out about technical details.

Mini Project

253

Block Description - SELECT

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

DESCRIPTION

1(5)

ETX/PN/CDD SBRT

ETX/PN/CDD

1551-CNT 216 9992 Uen

ETX/PN/CDD (Per Lundblad)

1997-04-23

BLOCK SELECT

Contents

General

Implementation

2.1

Block Structure

2.2

Data Structure

2.3

Program Structure

Interwork

3.1

External Signals

3.2

Internal Signals

3.3

Test Points and Operation Points

3.4

Commands

3.5

Printouts

Function

4.1

Start/Restart

4.2

Device State Print

Plex-C 2

254

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

DESCRIPTION

2(5)

1551-CNT 216 9992 Uen

1997-04-23

GENERAL

This block handles the command EXDSC. This command orders the DEVICE
block to seize an idle device. Block SELECT then prints a survey of the state of
the devices.

IMPLEMENTATION

2.1

BLOCK STRUCTURE

The block consists of one function unit implemented in central software.

2.2

DATA STRUCTURE

2.3

PROGRAM STRUCTURE

The function block SELECT is divided as follows:

START/RESTART

This segment takes part in two start/restart phases, symbolic phase 1 and 7.

DEVICE STATE PRINT

This segment handles the command EXDSC. The command orders block DEVICE
to seize an idle device and block SELECT generates a printout indicating the
seized device and a survey of the state of the devices in block DEVICE.

INTERWORK

3.1

EXTERNAL SIGNALS

3.1.1

Received Signals

Signal

Purpose

From

RSTATENUMR

Return state of

DEVICE

devices.

NODEVICE

Indicates that there

DEVICE

are no idle devices.

STTOR

Start signal at

start and restart.

Mini Project

255

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

DESCRIPTION

3(5)

1551-CNT 216 9992 Uen

1997-04-23

3.1.2

Sent Signals

Signal Name

Purpose

RSTATENUM

Request seizure of a

DEVICE

device a survey of

device states.

STTORRY

Indicate wanted

start/restart phases.

3.2

INTERNAL SIGNALS

3.2.1

CP - RP Signals (CP only)

3.2.2

RP - CP Signals (CP only)

3.2.3

CP - CP Signals (CP only)

3.3

TEST POINTS AND OPERATION POINTS

3.4

COMMANDS

EXDSC

Seize an idle device in the DEVICE block

and printout the seized device and

the number of devices in each state.

3.5

PRINTOUTS

Result Printouts

DEVICE STATE SURVEY

This printout gives a survey of the state of the devices in the DEVICE block.

FUNCTION

Plex-C 2

256

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

DESCRIPTION

4(5)

1551-CNT 216 9992 Uen

1997-04-23

4.1

START/RESTART

In symbolic phase 1, SELECT loads its own block reference. In symbolic phase
7, SELECT marks the function as idle.

SELECT receives signal STTOR with the start phase. The block checks if the
start phase is equal to symbolic phase 1 or 7. If the start phase does not correspond
to symbolic phases 1 or 7, SELECT takes no further actions and returns signal
STTORRY.

For symbolic phase 1, SELECT loads and stores its block reference and returns
signal STTORRY. For symbolic phase 7, SELECT marks the function as idle,
and then returns signal STTORRY.

Mini Project

257

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

DESCRIPTION

5(5)

1551-CNT 216 9992 Uen

1997-04-23

4.2

DEVICE STATE PRINT

The SELECT block receives command EXDSC that orders block DEVICE to
seize an idle device. The command results in a printout indicating the seized
device and the number of devices in each state.

The command EXDSC is a single user command. If the function is currently
marked busy, then the block prints "NOT ACCEPTED, FUNCTION BUSY" and
releases the I/O device.

If the function is idle, SELECT marks the function as busy and fetches the
parameter STATE. This parameter can have two values, ALL or IDLE. The block
analyses the parameter. If the command uses the parameter incorrectly, then
SELECT prints the message "NOT ACCEPTED" followed by a fault type.

If the parameter value is correct, SELECT prints "ORDERED", releases the I/O
device and sends the signal RSTATENUM to the DEVICE block. This signal
requests the seizure of an idle device and the identity of the seized device and
the number of devices in each state. The DEVICE block will return either the
signal RSTATENUMR or the signal NODEVICE.

If SELECT receives the signal RSTATENUMR then, the I/O device is seized
again. SELECT issues a printout varying in format according to the parameter
value specified in the command EXDSC. If the parameter value is ALL then, the
printout indicates the selected device and the number of devices in each state. If
the parameter value is IDLE then, the printout indicates the selected device and
the number of devices in the idle state only. Finally SELECT releases the I/O
device and marks the function as idle.

If SELECT receives the signal NODEVICE, then no idle device is available for
seizure. SELECT issues a printout including the string "NONE" for the selected
device. SELECT releases the I/O device and marks the function as idle.

Plex-C 2

258

Block Description - DEVICE

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

DESCRIPTION

1(6)

ETX/PN/CDD SBRT

ETX/PN/CDD

1551-CNT 216 9991 Uen

ETX/PN/CDD (Per Lundblad)

1997-04-24

BLOCK DEVICE

Contents

General

Implementation

2.1

Block Structure

2.2

Data Structure

2.3

Program Structure

Interwork

3.1

External Signals

3.2

Internal Signals

3.3

Test Points and Operation Points

3.4

Commands

3.5

Printouts

Function

4.1

Start/Restart

4.2

Size Alteration

4.3

Seize a device

Mini Project

259

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

DESCRIPTION

2(6)

1551-CNT 216 9991 Uen

1997-04-24

GENERAL

This block maintains a file of records each of which contains information relating
to the state of a device.

IMPLEMENTATION

2.1

BLOCK STRUCTURE

This course covers only the central software part of the block. In reality the block
would include hardware and software.

2.2

DATA STRUCTURE

The DEVICE block contains one file of records. The structure of this file is as
follows:

STATE

The global state of the devices

BLSTATE

Type of blocking specified

ADMSTATE

Device adminstration state

A pointer to the next IDLE record (device)

A pointer to the previous IDLE record (device)

2.3

PROGRAM STRUCTURE

The function block DEVICE contains the following segments:

START/RESTART

The block takes part in three Start/Restart phases, symbolic phases
1, 3 and 4.

SIZE ALTERATION

The block takes part in size alteration event 500.

SEIZE A DEVICE

If there are idle devices, the first idle device is seized (state is set
to busy).

Plex-C 2

260

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

DESCRIPTION

3(6)

1551-CNT 216 9991 Uen

1997-04-24

INTERWORK

3.1

EXTERNAL SIGNALS

3.1.1

Received Signals

Signal Name

Purpose

From

RSTATENUM

Request seizure of

SELECT

device and survey of

device states.

STTOR

Start signal at

start and restart.

GIVEFS

Get size alteration

SAF

data.

CONTFS

Check if alteration

SAF

can take place.

SETFS

Set file size.

SAF

3.1.2

Sent Signals

Signal Name

Purpose

RSTATENUMR

Return survey of

SELECT

device states.

NODEVICE

Indicates that there

SELECT

are no idle devices.

STTORRY

Return signal at

system start and

restart.

GIVEFSEND

Return size

SAF

alteration data.

CONTFSEND

Indicate if alteration

SAF

can take place.

SETFSEND

Size alteration

SAF

complete.

Mini Project

261

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

DESCRIPTION

4(6)

1551-CNT 216 9991 Uen

1997-04-24

3.2

INTERNAL SIGNALS

3.2.1

CP - RP Signals (CP only)

3.2.2

RP - CP Signals (CP only)

3.2.3

CP - CP Signals (CP only)

Signal Name

Purpose

CONTINUEB

Change to level B.

CONTINUEC

Phase devision at level C.

CLTIME0

Job table signal.

3.3

TEST POINTS AND OPERATION POINTS

3.4

COMMANDS

3.5

PRINTOUTS

FUNCTION

4.1

START/RESTART

This block takes part in three Start/Restart phases, symbolic phases 1, 3 and 4.

Signal STTOR is received with the start phase and start case. The DEVICE block
checks if the start phase is equal to start phase 1, 3 or 4. If not, DEVICE returns
the signal STTORRY without further actions.

For symbolic phase 1, the block loads and stores it’s own block reference.

For symbolic phase 3, the block checks the start case. For a start or a reload with
large restart, the block initializes the global and blocking states of all the devices
in the file depending on their administration state (ADMSTATE).

Plex-C 2

262

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

DESCRIPTION

5(6)

1551-CNT 216 9991 Uen

1997-04-24

For symbolic phase 4, the block sets the global state for each device depending
on start case and blocking state. These devices do not remain in speech position
after a small restart. Finally, the block creates the idle linked list.

After each symbolic start phase DEVICE returns the signal STTORRY with the
phases that the block participates in.

4.2

SIZE ALTERATION

The block receives signal GIVEFS with the number of the size alteration event. If
the number is not SAE 500, the block sends signal GIVEFSEND indicating that
the block does not take part in this size alteration event. If the number is SAE
500, the program fetches the file number of the corresponding file of records.
The block returns this file number and other information about the file with the
signal GIVEFSEND.

The block receives signal CONTFS and checks if it is a size alteration increase
or decrease. For a size alteration increase, the block verifies that the number of
records being added does not exceed a specified limit. If it does, then the block
sends the signal CONTFSEND indicating that the block does not take part in this
size alteration event.

For a size alteration decrease, the block clears the idle linked list and sets the
logical file size to zero. The program loops over all remaining records adding all
idle records to the new idle linked list and incrementing the logical file size. While
writing in stored variables, the program has to disable interrupts for a short time.
Next, the program checks if any of the records to be removed are currently busy.
If the program finds such a busy record, the block sends the signal CONTFSEND
indicating that the size alteration cannot continue. If the SAE passes all checks
successfully, the program sends signal CONTFSEND indicating that the block is
taking part in this size alteration event.

The program receives signal SETFS and checks if it is a size alteration increase
or decrease. For a size alteration increase, the block checks if a size alteration
decrease has been prepared (logical file size less that actual file size). If so, the
program loops over all records in the prepared decrement area adding all idle
records to the existing idle linked list and incrementing the logical file size.

For all size alteration increases, the program adds all new records to a temporary
idle list and sets their state to idle, their connection state to fully connected and
their blocking state to not blocked. When the temporary idle list is complete, the
program merges the existing and the temporary idle lists.
For both file size increase and decrease, the block sets the logical and actual
file sizes to the new number of records. While writing in stored variables, the
program has to disable interrupts for a short time. Finally the block sends signal
SETFSEND and the size alteration handling is complete.

Mini Project

263

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

DESCRIPTION

6(6)

1551-CNT 216 9991 Uen

1997-04-24

4.3

SEIZE A DEVICE

When the block receives signal RSTATENUM, DEVICE changes to the B level
by sending and receiving the signal CONTINUEB. Then the block checks if there
are any idle devices.

If there are no idle devices, the block returns the signal NODEVICE to the
SELECT block.

If there are idle devices, the first idle device is seized. The DEVICE block sends
signal RSTATENUMR to the SELECT block with the identity of the selected
device and the number of devices in each state.

4.3.1

Time supervision (additional exercise)

The devices in block DEVICE may stay in state BUSY not longer than 60
seconds. As soon as a device is seized and becomes BUSY, the block starts time
supervision for the corresponding record.

A timer record variable defines the supervision time in records with state BUSY.
A stored clock variable contains the internal clock value.

The block receives the job table signal every 15 seconds. If a record has state
BUSY for more than 60 seconds, the program sets the record state to IDLE
without further error message.

To reduce the processor load, this program segment uses phase division. The
program interrupts after scanning 500 device records.

Plex-C 2

264

Command Description - EXDSC

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

Command Description

1(3)

ETX/PN/CDD SBRT

ETX/PN/CDD

1/190 82-CNT 216 9992

ETX/PN/CDD (Per Lundblad)

1996-04-24

EXDSC

EXCHANGE DATA
DEVICE STATE, CHANGE

FORMAT

1.1

COMMAND

ALL

EXDSC:STATE=

;

IDLE

1.2

PARAMETERS

STATE

The parameter STATE specifies the type of

printout ordered. The STATE parameter can

accept the values ALL or IDLE.

Mini Project

265

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

Command Description

2(3)

1/190 82-CNT 216 9992

1996-04-24

FUNCTION

This command orders the seizure of an idle device in the device block and a
printout indicating the seized device.

If IDLE is specified, the printout also indicates the number of devices in the state
idle, in the device block. If ALL is specified then, the printout also contains the
number of devices in each state in the device block.

This command is a single user command. The order does not remain after system
restart.

EXAMPLES

3.1

EXAMPLE 1

EXDSC:STATE=ALL;

Seize an idle device in the device block and printout the number of devices in
each state and the number of the selected device.

3.2

EXAMPLE 2

EXDSC:STATE=IDLE;

Seize an idle device in the device block and printout the number of devices in
the idle state only and the number of the selected device.

Plex-C 2

266

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

Command Description

3(3)

1/190 82-CNT 216 9992

1996-04-24

PRINTOUTS

4.1

CHECK PRINTOUT

No.

4.2

PROCEDURE PRINTOUTS

ORDERED

The printout has been ordered.

NOT ACCEPTED

The command has not been accepted.

faulttype

Faulttype:

FUNCTION BUSY

Function busy.

FORMAT ERROR

Format error.

UNREASONABLE VALUE

Unreasonable value.

details

4.3

ANSWER PRINTOUTS

4.4

RESULT PRINTOUTS

DEVICE STATE SURVEY

LOGGING

No.

COMMAND CATEGORY GROUP

Recommended value 53 (H’35)

COMMAND RECEIVING BLOCK

SELECT

Mini Project

267

Printout Description - Device State Survey

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

Printout Description

1(3)

ETX/PN/CDD SBRT

ETX/PN/CDD

1/190 83-CNT 216 9992

ETX/PN/CDD (Per Lundblad)

1997-04-28

DEVICE STATE SURVEY

FORMAT

1.1

PRINTOUT

DEVICE STATE SURVEY

SELC

<IDLE>

<BUSY

BLOC

SEBU>

<nbsy

nblc

nseb>

<NONE>

END

Plex-C 2

268

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

Printout Description

2(3)

1/190 83-CNT 216 9992

1997-04-28

1.2

PARAMETERS

selc

The selected device.

nidle

Number of idle devices.

nbsy

Number of busy devices.

nblc

Number of blocked devices.

nseb

Number of semi-permanently busy devices.

NONE

Failure to seize a device.

Appears,

when none of the devices in the

device block are in the idle state.

FUNCTION

The command EXDSC orders this printout. The printout provides a survey of
the state of the devices in the device block, and indicates which device has been
selected. The format of the printout depends on the parameter value specified in
command EXDSC.

2.1

PRINTOUT FORMAT

If the device block did not have any idle records, the printout does not include the
state counters for IDLE, BUSY, BLOC and SEBU. The printout only contains
the title, SELC, NONE, and then END.

If parameter state was IDLE, the printout does not include the state counters for
BUSY, BLOC and SEBU.

2.2

EXAMPLE 1

EXDSC:STATE=ALL;

The printout indicates the number of

devices in each state in the device

block and the selected (seized) device.

2.3

EXAMPLE 2

EXDSC:STATE=IDLE;

The printout indicates the number

of devices in the idle state only,

the selected (seized) device, in

the device block.

Mini Project

269

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

Training Document

Printout Description

3(3)

1/190 83-CNT 216 9992

1997-04-28

ACTION

PRINTOUT TYPE

Result Printout

PRINTOUT BLOCK

SELECT

Plex-C 2

270

Signal Descriptions

rstatenum.signal

14:31:52

23 Apr 97

0. DOCUMENT RSTATENUM;
1.
2. SIGNAL RSTATENUM;
3. ! TRAINING DOCUMENT ONLY !
4. ! FUNCTION: SEIZE AN IDLE RECORD IN THE DEVICE FILE !
5. ! AND REQUEST DEVICE STATE INFORMATION !
6.
7. TYPE 1 CP-CP; ! SINGLE SIGNAL !
8.
9. ! POSSIBLE RETURN SIGNAL: RSTATENUMR

10. NODEVICE !
11.
12. ! COMMUNICATION: SENDER: SELECT
13. RECEIVER: DEVICE !
14.
15.
16. LEVEL C;
17.
18. DATA D1 16, ! SENDING INDIVIDUAL !
19. D2 16; ! SENDING BLOCK !
20.
21. ! DETAILED DATA DESCRIPTION:
22. D2 SENDING BLOCK REFERENCE !
23.
24. END SIGNAL;
25. *END;
26. ID RSTATENUM TYPE DOCUMENT;
27. CLA 998/15514;
28. NUM APT 210;
29. REV B;
30. DES ETX/PN/CDD SBRT;
31. RES ETX/PN/CDD;
32. APP ETX/PN/CDD;
33. END ID;
34.

Mini Project

271

rstatenumr.signal

14:34:40

23 Apr 97

0. DOCUMENT RSTATENUMR;
1.
2. SIGNAL RSTATENUMR;
3.
4. ! TRAINING DOCUMENT ONLY !
5. ! FUNCTION: RETURN REQUESTED DEVICE STATE INFORMATION !
6.
7. TYPE 1 MULTIPLE CP-CP; ! SINGLE SIGNAL !
8.
9. ! RETURN SIGNAL TO: RSTATENUM !

10.
11.
12. ! COMMUNICATION: SENDER: DEVICE
13. RECEIVER: USER BLOCKS !
14.
15. LEVEL C;
16.
17. DATA D1 16, ! ADDRESSED INDIVIDUAL !
18. D2 16, ! NUMBER OF IDLE DEVICES !
19. D3 16, ! THE IDLE DEVICE SELECTED !
20. D4 16, ! NUMBER OF BUSY DEVICES !
21. D5 16, ! NUMBER OF BLOCKED DEVICES !
22. D6 16; ! NUMBER OF SEMIPERMANENTLY BUSY DEVICES !
23.
24.
25. END SIGNAL;
26. *END;
27. ID RSTATENUMR TYPE DOCUMENT;
28. CLA 999/15514;
29. NUM APT 210;
30. REV B;
31. DES ETX/PN/CDD SBRT;
32. RES ETX/PN/CDD;
33. APP ETX/PN/CDD;
34. END ID;

Plex-C 2

272

nodevice.signal

15:52:21

26 May 97

0. DOCUMENT NODEVICE;
1.
2. SIGNAL NODEVICE;
3.
4. ! TRAINING DOCUMENT ONLY !
5. ! FUNCTION: NO IDLE DEVICE !
6.
7.
8. TYPE 1 MULTIPLE CP-CP; ! SINGLE SIGNAL !
9.

10.
11. ! RETURN SIGNAL TO: RSTATENUM !
12.
13.
14. ! COMMUNICATION: SENDER: DEVICE
15. RECEIVER: SELECT !
16.
17.
18. LEVEL C;
19.
20. DATA D1 16; ! ADDRESSED INDIVIDUAL !
21.
22.
23. END SIGNAL;
24. *END;
25. ID NODEVICE TYPE DOCUMENT;
26. CLA 997/15514;
27. NUM APT 210;
28. REV B;
29. DES ETX/PN/CDD SBRT;
30. RES ETX/PN/CDD;
31. APP ETX/PN/CDD;
32. END ID;

273

Chapter 16

Command STDEP

Command Description - STDEP . . . . . . . . . . . . . . . . . . . . . . . . . 286

Printout Description - Device State Details . . . . . . . . . . . . . . . . . 289

Plex-C 2

274

Command Description - STDEP

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

COMMAND DESCRIPTION

1(3)

LMI/Dd JCUM

EEI/STF

2/190 82-CNT 216 1174 Ue

ETX/TX/FK (B ERIKSSON)

1993-06-23

STDEP

DEVICE STATE FOR DEVICES, PRINT

FORMAT

1.1

COMMAND

STDEP: DEV = dev . . .;

1.2

PARAMETERS

DEV = dev

Device number.

FUNCTION

The command orders a printout of states for telephony devices.

EXAMPLES

STDEP:DEV=ITCPN-75&-77;

An inquiry on device states for connection lines of type ITCPN with the numbers
75 and 77.

PRINTOUTS

4.1

CHECK PRINTOUT

No.

4.2

PROCEDURE PRINTOUTS

NOT ACCEPTED

fault type

Command STDEP

275

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

COMMAND DESCRIPTION

2(3)

2/190 82-CNT 216 1174 Ue

1993-06-23

Fault types:

FORMAT ERROR

Format error.

UNREASONABLE VALUE

Unreasonable value, overaddressing.

Plex-C 2

276

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

COMMAND DESCRIPTION

3(3)

2/190 82-CNT 216 1174 Ue

1993-06-23

FAULT CODE 1

No free individuals.

Action:

Make a size increase of the

number of records in DESI,

SAE = 500.

FAULT CODE 6

Unreasonable blocktype.

Inquiries on device states may not

be made for specified block type.

4.3

ANSWER PRINTOUTS

DEVICE STATE DETAILS

4.4

RESULT PRINTOUTS

LOGGING

No.

COMMAND CATEGORY GROUP

Recommended value 0 (H’0).

COMMAND RECEIVING BLOCK

DESI

Command STDEP

277

Printout Description - Device State Details

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

PRINTOUT DESCRIPTION

1(4)

LMI/DUP PGEN

EEI/STF

1/190 83-CNT 216 1174 Uen

LMI/X/MHA (C MARTIN)

1993-08-13

DEVICE STATE DETAILS

FORMAT

1.1

PRINTOUT

Plex-C 2

278

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

PRINTOUT DESCRIPTION

2(4)

1/190 83-CNT 216 1174 Uen

1993-08-13

DEVICE STATE DETAILS

DEV

STATE

BLS/FS

ADM

ABS

SNB

dev

state

bls fs

adm

abs

snb

dev

state

bls fs

adm

abs

snb

DEV

STATE

BLS/FS

ADM

ABS

SNB

dev

state

bls fs

adm

abs

snb

dev

state

bls fs

adm

abs

snb

Command STDEP

279

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

PRINTOUT DESCRIPTION

3(4)

1/190 83-CNT 216 1174 Uen

1993-08-13

1.2

PARAMETERS

dev

Device number

state

Device state

BLOC

Blocked device.

LIBL

Line-blocked device.

SEAL

Sealed device.

TEST

Test blocked device.

LOUT

Locked-out subscriber line.

IDLE

Idle device.

INCO

Device seized for incoming

traffic (only for bothway

circuits).

BUSY

Busy device

SEBU

Semipermanent busy device.

bls

Blocking state

MBL

Manual blocking.

ABL

Automatic blocking.

TBL

Test blocking.

CBL

Blocking from the control

system.

If one of the fault markings F, C, L, S, D is to be

printed it will appear immediately to the right of the

blocking state column,under the FS heading.

Fault state

Fault suspected line at

subsciber line supervision.

Fault suspected circuit at

subscriber line circuit

supervision.

Fault suspected line and

circuit at subscriber line and

circuit supervision.

Fault suspected seizure

quality supervision.

Fault suspected at disturbance

supervision.

Plex-C 2

280

Uppgjord -

Prepared

Kontr -

Checked

Datum -

Date

Rev

Dokansv/Godk -

Doc respons/Approved

Nr -

No.

File

Faktaansvarig -

Subject responsible

PRINTOUT DESCRIPTION

4(4)

1/190 83-CNT 216 1174 Uen

1993-08-13

adm

Administrative state

Not connected device.

abs

Absolute state

Local state in the

device block.

Route

Route identification. If a

route has affiliated routes

they will all be printed out.

snb

Subscriber

For group number line which

number

lacks own subscriber number

the group number is given.

FUNCTION

The printout is received as an answer printout to the commnds STDEP, STRDP,
and STBSP. Device states are printed for the specified devices. After commands
STDEP AND STBSP, the identity of the route containing the device will also
be printed, if there is one. For bothway routes all affiliated routes will also be
printed. For LI devices subscriber number is given instead of a route identity. If
an LI device is connected to a PBX line the group number will be printed if an
individual number is not found. The interpretation of local state (ABS) values
can be found in the program information (code generation) of the device block,
if required.

ACTION

PRINTOUT TYPE

Answer Printout.

281

Chapter 17

Index

2/AI

169

2/Application Information

169

Absolute Start Phases

112

Access Times

35, 218

Adaptation Direction

ADDRDATA

232

ADI

ADMSTATE

118, 188

Alterable File Size

163

AOTU

Application System

Approved Correction

APZ

17, 139

APZ 212

Arrays

218

Authorization Check

Automatic Dump

BAL 1

141

BAL 2

141

Base Level 1

141

Base Level 2

141

BLOCK

Block Category

107

Block Characteristics

Block Masking Symbol

Block References

finding

Block Type

55, 242

Example

Block Type Extension

55, 242

BLSTATE

118, 188

BUFFER

Buffer

218

Buffer Congestion

148

Category Number

Central Processor

Central Processor Subsystem

Check Printout

Check Printouts

Plex-C 2

282

CHKFUCODE

CINDNUM

168

CLEAR

C-Level Rule

151

Clock-Timer

204

algorithm

207

program

207

supervision accuracy

207

CLSCAN0

202

CLTIME0

200, 204

227

CN-I

COCA

33, 75

COCA number

COD

70, 274

Command Category Number

33, 74

Command Description

command description

274

Command Log

32, 74

Command Logging

Command Parameters

Command Reception

multiple users

Command STDEP

93, 273

Command Syntax

Commands

CONTFS

178, 192

CONTFSEND

193

CONTINUEB

148

CONTINUEC

148

CONTINUED

148

Control Module

227

Control System

17, 139

Correction Note Issue

executive

standby

CP-EMRP

223

CP-EMRP Unit Interaction

236

CPREPNUM

168

CP-RP

223

CP-RP Unit Interaction

231

CPS

CSR2U

232

Data Communication Subsystem

Data Store

database management subsystem

DBS

DCI

Syntax

DCS

Index

283

Deblocking

a Device

187

Design

efficient programming

217

Design Descriptions

Design Rules

Details

DEVADDR

232, 236

DEVICE

244

Device

deblocking

187

DRtool

28, 34

DUMP

Dump Handling

Dumping

Efficient Design

217

227

EMB

224

Emergency Correction

EMRP

225, 230

EMRPD

226

EOT

Error Code (system recovery)

108

Error Printouts

Exchange-dependent Parameter

Execution Time Limits

147

Execution Times

146

Exercise 1

Design Rules

240

Exercises

239, 247

Extension Module

227

FC conversion tables

FCMANBLOC

FESR

220

FETCH PARAMETER

File Management Subsystem

File RELFSW0

File Size

163

FILESIZE statement

235, 237

Finding Block References

Fixed File Size

163

FMS

FOR ALL

220

FOR FIRST

220

Forlopp

Förlopp

Forlopp Identity

105

Plex-C 2

284

Forlopp Manager

105

Forlopp Release

104

FORMAT ERROR

Function Change

Method 1

Method 2

Function Codes

Furax

Furaxtool

Fuspel

GIVEFS

176, 190

GIVEFSEND

191

I/O

documents

Idle Load

217

Indexed Linked Lists

time supervision

213

Initial Loading

26, 100

Input-Output Documents

INSERT

INSERT STRING

INSERT TAB

Intensity Counter

104

Interference Problems

with I/O statements

Interrupt

147

prevention

158

INTERVAL IS

200

IOCODE

in WRITE

Iterations

220

JBA

142, 144

JBB

144

JBC

144

JBD

144

Job

140

Job Buffer

144

Job Buffer Level A

142

Job Table

142, 143, 199

Job Table Signals

199

JOBTABLE DELETE

201

JOBTABLE INSERT

200

KR2U

236

Index

285

Large Data Dump

Level Change

152

Linking of Records

logical file size

168

Loops

220

Main store

Maintenance Subsystem

Malfunction Level

140

Man-machine Communication Subsystem

Manual Dumping

Market-dependent Parameter

MAS

Masking

MCS

MEDAX

Memory

efficient use

219

Methods Documents

MFL

140

MHS

Mini Project

243

MISSRA

100

Modification Handling System

MRP

229

Multiple signals

Multiple Users

command reception

Normal Case

220

NOT ACCEPTED

NSYMB

220

Operational Instruction

OPI

Optional Blocks

Parameter

exchange-dependent

market-dependent

Parameter List

3, 59

PARTLY EXECUTED

Phase Division

148

Implementation

148

physical file size

168

3, 59

Plex-M

231

Plex-C 2

286

Plex-SQL

POD

70, 277

Printout Description

70, 277

Printout Example

Printout Types

Printouts

Priority System

140

Procedure Printouts

Processor Capacity

218

Processor Load

217

Product Line

Program Administration

139

Program Store

R (variable property)

Reference Store

Regional Processor

225

Regional Processor Subsystem

141

RELOAD (variable property)

RELOAD VARIABLE (macro)

Result Printouts

REX

229

RP Functions

224

RP1

225

RP2

225

RPB

223

RPD

226

RPG

226

RPRESKR

135

RPS

18, 223

SAE

Flowcharts

175

global

165

hardware files

187

local

165

Signalling

173

SAF

167

SELECT

244

Selection of Level

152

Selective Restart

107

SETFS

183, 195

SETFSEND

196

Signal Communication

Signalling Level

restart

124

Signals

219

Index

287

Size Alteration

163

flowcharts

175

Hardware files

187

operation

166

Scenarios

170

signalling

173

Size Alteration Event

global

165

local

165

Small Data Dump

Software Recovery

Software Reliability Handbook

Source Parameter List

Source System

225

SPH1

114

SPH2

114

SPH3

114

SPH4

116

SPH5

116

SPH6

116

SPH7

116

SPL

SPS

SQL

Standard Texts

Start of EMRP

122

Start of RP

122

STARTCASE

123

STATE

118

STATIC

35, 36

Stop-Clock

215

STOREFUCODE

STTOR

123, 127

STTORRY

123, 128

Subroutines

221

Support Processor Subsystem

SWRH

Symbolic Start Phases

112

SYNTAX ERROR

Syntax Error

System Characteristics Handbook

System Recovery

102

System Restart

background

109

reasons

109

System Start

Temporary Variables

Text Codes

THL

140

THL1

199

Plex-C 2

288

THL2

142

Time Gaps

Time Limits

147

Time Measurement

203, 215

Time Queue

145

Time Supervision

203

TOMAX

TQA

145

TQB

145

TQC

145

TQD

145

Trace Level

140

Traffic Handling Level

140

Traffic Load

217

TRAN

83, 88

TRAN1

83, 88

TRL

140

Trouble Report

TYPE

Type Extension

242

TYPEEXT

Unique signals

UNREASONABLE VALUE

UPDARPKR

134

Usage Load

217

USE

Variable Interference

153

avoiding

157

Variable Properties

WRITE

Ericsson Telecom AB
MV/ETX/X/HCD
S-126 25 Stockholm, Sweden

ETX/Ericsson Telecom AB, Stockholm, December 1997

EN/LZT 101 1280 R4A



Ericsson Telecom AB

Document Outline

PLEX-C2
PREFACE
Chapter 1 Design Essentials
Chapter 2 APZ Basics
- Introduction
  - Figure 2.1
- APZ
  - Data Processing
  - Input-Output Handling
    - Figure 2.2
  - CPS
  - RPS.
  - MAS
  - DBS
  - SPS
  - MCS
  - DCS
  - FMS
  - Figure 2.3
  - Fault Detection
    - Table 2.1
  - Database Management Subsystem
  - Evolution of the APZ
    - Table 2.2
    - Figure 2.4
- Chapter Summary
  - Figure 2.5
- References
  - [1]
  - [2]
  - [3]
  - [4]
  - [5]
  - [6]
  - [7]
  - [8]
Chapter 3 Loading, Dumping and Variable Properties
- Introduction
  - Figure 3.1
- General
- Initial Loading
  - Figure 3.2
  - Figure 3.3
- Dumping
  - Figure 3.4
    - SYBUP
    - SYBUI
    - SYBTS
  - Large Data Dump
  - Small Data Dump
- Dump Handling
  - FFR
  - SFR.
  - Figure 3.5
  - Figure 3.6
    - R0
    - R1/R2
    - R3/R4
    - R5
- Reloading
- Variable Properties
  - Figure 3.9
    - Temporary variables
    - DS
    - BUFFER
    - CLEAR
    - RELOAD
    - DUMP
    - STATIC
    - R
      - Table 3.1
      - Table 3.2
- Function Change
- Function Change Procedure
- Chapter Summary
  - Figure 3.20
- References
  - [1]
  - [2]
  - [3]
  - [4]
  - [5]
  - [6]
  - [7]
  - [8]
  - [9]
  - [10]
Chapter 4 CP-CP Unit Interaction
Chapter 5 Commands
Chapter 6 Printouts
- Introduction
  - Figure 6.1
- Printout Statements
  - Figure 6.2
  - Translation Functions
    - Figure 6.3
- WRITE
- Printout Types
- Summary
  - Table 6.1
  - Printout Example
    - Figure 6.8
      - Table 6.2
- Standard Text Codes
  - Figure 6.9
- Chapter Summary
  - Figure 6.10
- References
  - [1]
  - [2]
  - [3]
  - [4]
  - [5]
  - [6]
  - [7]
  - [8]
  - [9]
  - [10]
Chapter 7 Software Recovery
Chapter 8 Job Execution
Chapter 9 Size Alteration
Chapter 10 Job Table Signals
- Introduction
  - Figure 10.1
- Concept
- Plex-C Statements
  - Figure 10.2
- Restrictions
- References
  - [1]
  - [2]
  - [3]
  - [4]
Chapter 11 Time Supervision and Time Measurement
Chapter 12 Efficient Design
Chapter 13 CP-RP/EMRP Interaction
- Introduction
  - Figure 13.1
- Regional Processor Subsystem
- Regional Processors
  - Figure 13.2
  - Software Functions of RP
    - Figure 13.3
- Types of Regional Processors
  - RP1
  - EMRP
  - RP2
  - SP
  - RPD
  - EMRPD
  - Figure 13.4
    - RPG
- Extension and Control Modules
  - Figure 13.5
- RP2 Functions
  - Figure 13.6
  - RP2 Software
    - Figure 13.7
- EMRP Functions
  - Figure 13.8
- CP-RP Unit Interaction
- CP-EMRP Unit Interaction
  - Figure 13.15
  - Code Summary
    - Figure 13.16
- Chapter Summary
  - Figure 13.17
- References
  - [1]
  - [2]
  - [3]
  - [4]
  - [5]
  - [6]
  - [7]
  - [8]
  - [9]
Chapter 14 Exercises
- Exercise 1: Design Rules
- Exercise 2: Block Type and Type Extension
Chapter 15 Mini Project
Chapter 16 Command STDEP
- Command Description - STDEP
- Printout Description - Device State Details
Chapter 17 Index
- A
- B
- C
- D
- E
- F
- G
- I
- J
- K
- L
- M
- N
- O
- P
- R
- S
- T
- U
- V
- W

Wyszukiwarka

Podobne podstrony:
plex c1 en lzt 101 1279 r7a M5DZGPRAMMEDT6LYUYAYBVE2VK5OFZVG7X67AUY
plex c1 en lzt 101 1279 r7a M5DZGPRAMMEDT6LYUYAYBVE2VK5OFZVG7X67AUY
KR C2 ed05 Battery Monitoring en
BA KR C2 ed05 Main Switch with Cover en
101 AMESYS EAGLE SMINT en
101 Garb zniewolenia sowieckiegoid 11503 ppt
Budzik Versa wielkość karty kredytowej instrukcja EN
G2 4 PW EN wn Rys 01
Manual Acer TravelMate 2430 US EN
Mazowieckie Studia Humanistyczne r1998 t4 n1 s79 101
Ćwiczenie 01 EN DI
eci en
BVSOI 3 001 E en
A Biegus projektowanie konctrukcji stalowych wg PN EN 1993 1 1 cz 1
Flavon Active dopping EN
5817 PN EN ISO IV 2007
Pisownia ę ą en em om

więcej podobnych podstron

plex c2 en lzt 101 1280 r4a OTVWMSCOVBTAW2VOFXUTIQEGQLHVCV4K6OJPGHA

Document Outline