PLEX-C 1

PREFACE

This book is a course document for Ericsson’s internal training pro
grammes. Thus, the book contains some simpliﬁcations and cannot replace
a speciﬁcation of the system.

The contents of this book are subject to revision without notice due to con
tinuous development in design and manufacture.

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

Any comments on this student book and the course in general are most
welcome.

Ericsson Telecom AB

Internal Training Marievik, MV/ETX/PN/CDD

Ericsson Telecom AB December 1998, Stockholm, Sweden

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

981210

Table of Contents

Course Introduction

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .IX
Overall Objectives of the Course . . . . . . . . . . . . . . . . . . . . . . . . . . . .IX
Entry Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .IX
Day-by-Day Course Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X

AXE Survey

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
What is Plex? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
AXE System Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
AXE Programming Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
AXE Central Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Addressing Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Source System, Product Line, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
and Application System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Documents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Document Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Software Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

Identity Sector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Document Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Source Program Information (SPI) . . . . . . . . . . . . . . . . . . . . .17
Parameter List (PL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Source Parameter List (SPL) . . . . . . . . . . . . . . . . . . . . . . . . . .17
Signal Description (SD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Signal Survey (SS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

From Plex to Object Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Analysing Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Basic Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

PLEX-C1

Declare Sector

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Introduction to Plex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

A Plex-C Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
System-Defined Characters . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Metasyntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

Variable Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

Field Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
R Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
One-Dimensional Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

Two-Dimensional Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

Symbol Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

String Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

Variable Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Symbol Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

Global Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Local Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50

Program Sector

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Programming Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

Program Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Arithmetic Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Logic Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Operand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Field Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56

Assignment Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

Restrictions for using R Variables . . . . . . . . . . . . . . . . . . . . . .60

Jump Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

Unconditional Jump Statement . . . . . . . . . . . . . . . . . . . . . . . .62
Conditional Jump Statement . . . . . . . . . . . . . . . . . . . . . . . . . .63

Conditional Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
Selection Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Iteration Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68

The ON Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
The FOR ALL statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
The FOR FIRST statement . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
High-Speed Iterations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
FESR Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
FIRSI Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
Loop Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

Old Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80

BRANCH Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
ON CARRY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83

Data Sector

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
File-Size Definition Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Variable Assignment Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

Common Variable Assignment Statements . . . . . . . . . . . . . . .88
Individual Variable Assignment Statements . . . . . . . . . . . . . .89

Allocating Variables in the Data Store . . . . . . . . . . . . . . . . . . . . . . .90

Addressing Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
Storing Individual Variables . . . . . . . . . . . . . . . . . . . . . . . . . .93
Allocation Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
Reasons for Variable Allocation . . . . . . . . . . . . . . . . . . . . . . .96

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97

III

PLEX-C1

Block Interaction

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
What is a Signal? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99

A Subprogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101
Some Implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102
Delayed Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
Different Types of CP-CP Signals . . . . . . . . . . . . . . . . . . . . .103
RP Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105

Plex-C Statements for Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106

Signal Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
Single Signal Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
Combined Signal Statements . . . . . . . . . . . . . . . . . . . . . . . . .113

Job Buffers and the Job Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116

Job Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116
The Job Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
Time Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
Job Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
Execution Time Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122

Addressing Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
Signal Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126

Signal Distribution Table (SDT) . . . . . . . . . . . . . . . . . . . . . .126
Signal Sending Table (SST) . . . . . . . . . . . . . . . . . . . . . . . . . .127
Global Signal Distribution Tables (GSDT) . . . . . . . . . . . . . .127
Block Interaction – Addressing with Unique Signals . . . . . .129
Multiple Signal Sending . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
Some APZ 212 20 Characteristics . . . . . . . . . . . . . . . . . . . . .130

Signal Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131

Content of a Signal Description . . . . . . . . . . . . . . . . . . . . . . .131
Descriptions for CP-RP and RP-CP Signals . . . . . . . . . . . . .135
R Variables and Signal Descriptions . . . . . . . . . . . . . . . . . . .137
Content of a Signal Survey . . . . . . . . . . . . . . . . . . . . . . . . . .139

Local Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144

Call Routines

145

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145
Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146

Statement Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
Assembly Language Sector . . . . . . . . . . . . . . . . . . . . . . . . . .147

Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148

Call to a Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149

Block Number and Block Reference . . . . . . . . . . . . . . . . . . . . . . . .150
Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152

Input and Output Statements

153

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153
Alphanumeric and File-oriented Input/Output . . . . . . . . . . . . . . . .153
Statements for Alphanumeric Input/Output . . . . . . . . . . . . . . . . . .155

Command Receiving Statement . . . . . . . . . . . . . . . . . . . . . . .156
Command Rejection Statement . . . . . . . . . . . . . . . . . . . . . . .160
Seizure of an I/O Device . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
Release of an I/O Device . . . . . . . . . . . . . . . . . . . . . . . . . . . .165

Fetching Information from an Analysis Buffer . . . . . . . . . . . . . . . .167
Output of Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179

Writing on an I/O Device from Line Buffer . . . . . . . . . . . . .189

Reading from an I/O Device to Analysis Buffer . . . . . . . . . . . . . . .193
Overview of Alphanumeric I/O Statements . . . . . . . . . . . . . . . . . .195
Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196

Buffers and Structures

197

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
Structured Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198

Variants of Structured Buffers . . . . . . . . . . . . . . . . . . . . . . . .200
Memory Use of Structured Buffers . . . . . . . . . . . . . . . . . . . .201

Communication Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202

Restart Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202
Allocating Communication Buffers . . . . . . . . . . . . . . . . . . . .202

Dynamic Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207

Allocating Dynamic Buffers . . . . . . . . . . . . . . . . . . . . . . . . .208
Multiple Buffer Pointers . . . . . . . . . . . . . . . . . . . . . . . . . . . .213

Buffers in Signal Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213
Use of Communication and Dynamic Buffers . . . . . . . . . . . . . . . . .214

Local and Global Variables . . . . . . . . . . . . . . . . . . . . . . . . . .214

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217

PLEX-C1

AXE Parameters

219

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219
Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222

Parameter Sector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222
Declare Sector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .225
User Code Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227
Deferred Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228
Parameter Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230
Application Parameter Distribution . . . . . . . . . . . . . . . . . . . .231

Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232

Parameter Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232
Parameter SetNames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232
Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232

Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233
Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234

Data Structures

235

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235
Linked Lists in the Subscriber Switch . . . . . . . . . . . . . . . . . . . . . . .235

Single-Linked Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238
Double-Linked Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239

Implementing Logic in the Data or in the Program Structure . . . . .244
Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247

Design Environment

249

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249
APStools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249
APS Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249

Customising APStools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256

Editing and Analysing Plex documents . . . . . . . . . . . . . . . . . . . . . .262
Testing with the Emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .272
Browsing Code with PlexView . . . . . . . . . . . . . . . . . . . . . . . . . . . .276
APZ Emulator Commands in EmuTool . . . . . . . . . . . . . . . . . . . . .287

Appendix

297

Addressing: Multiple and RP-CP Signals 299

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .299
Multiple Signal Sending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .299

Global Signal Distribution Table for Multiple Signals . . . . .300

Addressing for RP-CP signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . .304

File-Oriented Input and Output

309

Seizure of File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311

Writing a Block to a File . . . . . . . . . . . . . . . . . . . . . . . . . . . .314
Reading from a File into a Block . . . . . . . . . . . . . . . . . . . . . .316
Release of File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317
Overview of File-Oriented I/O statements . . . . . . . . . . . . . . .318

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .320
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .320

VII

PLEX-C1

Exercises

321

Exercise 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .321
Exercise 3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325
Exercise 3.3 a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
Exercise 3.3 b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
Exercise 3.3 c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
Exercise 3.3 d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
Exercise 3.3 e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
Exercise 3.3 f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
Exercise 3.3 g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327
Exercise 3.3 h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327
Exercise 3.3 i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327
Exercise 4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .328
Exercise 4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .328
Exercise 4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .328
Exercise 4.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329
Exercise 4.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329
Exercise 4.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .330
Exercise 4.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .330
Exercise 4.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .331
Exercise 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .333
Exercise 6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334
Exercise 6.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334
Exercise 6.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334
Exercise 6.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334
Exercise 7.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .335
Exercise 7.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .339
Exercise 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .343
Exercise 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
Exercise 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348
Exercise 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349

Index

359

VIII

Course Introduction

Introduction

This book is a training document for the Plex-C 1 course. The course teaches how
to write and check Plex-C code following syntax rules and semantics.

Overall Objectives of the Course

After completing this course, the students are able to design and check programs
in Plex-C according to syntax and semantics. The students are able to use
advanced data structures and create code that is efﬁcient regarding memory and
time consumption.

Students entering this course have to be familiar with basic programming con
cepts (for example, FOR loops) and data structures (for example, integer, pointer
and array variables). The students should also feel conﬁdent with UNIX worksta
tions and the OpenWindows environment.

Students ought to attend the Plex-C 2 course after the Plex-C 1 course. The Plex-
C 2 course teaches them how write programs according to design rules. In partic
ular, Plex-C 2 covers critical concepts such as initial load, variable dumping,
function change, software recovery, ﬁle size alteration, phase division and level
change, time supervision and time measurement, and command and printout han
dling.

Entry Requirements

The participants should have completed the following courses in the “AXE Train
ing Path for Block Designers”, or equivalent training:

•

Telecom Platform

•

AXE 10, Survey

•

UNIX, Basics

•

Programming Methods in C

•

AXE 10, APT

Plex-C 1

Da y-b y-Da y Cour se Plan

The duration of this course is 6 days.

Day 1

•

Presentation

•

Chapter 1, AXE Survey

•

Chapter 2, Documents

•

Chapter 3, Declare Sector

•

Exercises

Day 2

•

Introduction to APStools (Chapter 12, Design Environment)

•

APStools: Analyzetool and editor (Chapter 12, Design Environment)

•

Exercises

•

Chapter 4, Program Sector

•

Exercises

Day 3

•

Chapter 5, Data Sector

•

Exercises

•

Chapter 6, Block Interaction

•

Exercises

Day 4

•

Chapter 7, Call Routines

•

APStools: EmuTool and PlexView (Chapter 12, Design Environment)

•

Exercises

Day 5

•

Chapter 8, Input and Output Statements

•

Exercises

Day 6

•

Chapter 9, Buffers and Structures

•

Chapter 10, AXE Parameters

•

Chapter 11, Data Structures

•

Exercises

•

Conclusion

Chapter 1

AXE Survey

Introduction

To understand the Plex-C programming language you need a basic understanding
of AXE. This chapter introduces Plex-C and describes some basic AXE concepts.

Chapter Objectives

• the structure of the AXE system

• the programming languages used in the AXE processors

• the memory in the AXE processor

• the concepts of source system, product line and application system

After completing this chapter, the student is familiar with:

Figure 1.1

Chapter Objectives

What is Plex?

PLEX is an acronym for Programming Language for EXchanges and is a high-
level language developed by Ericsson in the 1970s, and extended in 1983. Pro
grams in the AXE central processors use the Plex version Plex-C. The EMRP,
which controls the subscriber stage, runs programs in Plex-M, a different dialect
of Plex.

Plex is a high-level, real-time, language with very strict requirements regarding
execution time. These features are discussed in the table on page 2.

Ericsson developed its own language, Plex, because in 1970 no other language
existed that fulﬁlled Ericsson’s requirements. Plex programs have a modular
structure. The modules cooperate using signals. It is possible to modify one mod
ule without affecting the others. An AXE exchange may exist for up to 40 years,
which implies certain requirements regarding the operation and maintenance of
the software.

Plex serves telephony purposes only, but it is by no means an insigniﬁcant pro
gramming language. Plex code runs in thousands of exchanges all over the world
and is used by thousands of designers.

Plex-C 1

Feature

Explanation

A high-level programming language uses commands independent of

high-level

the processor type. High-level commands are general, and usually
translate into several different instructions at the machine level.

Plex-C is a programming language designed exclusively for telephony

single-purpose

systems. It therefore lacks common statements from other program
ming languages such as WHILE loops, negative numeric values or
real numbers. These elements are not needed in telephony.

real-time

Telephony software must execute as fast as possible. Our programs
have to meet certain time limits speciﬁed by our customers and by
international telecommunications standards organizations. Plex-C
programming allows to predict execution times, even when different
jobs are handled at the same time.

Table 1.1

Main characteristics of Plex-C

AXE System Structure

The AXE system consists of two main parts:

•

APT, the telephony or switching part

•

APZ, the control part including central and regional processors

Both APT and APZ consist of hardware and software. APT and APZ are divided
into subsystems, some of which are shown in Figure 1.2.

Subsystems of APT

Subsystems of APZ

TCS

Trafﬁc Control Subsystem

CPS

Central Processor Subsystem

TSS

Trunk and Signalling Subsystem

MAS

Maintenance Subsystem

GSS

Group Switching Subsystem

RPS

Regional Processor Subsystem

OMS

Operation and Maintenance Subsystem

MCS Man-machine

SSS

Subscriber Switching Subsystem

Communication Subsystem

CHS

Charging Subsystem

DCS

Data Communication Subsystem

SUS

Subscriber services Subsystem

FMS

File Management Subsystem

OPS

Operator subsystem

DBS

Database Management

CCS

Common Channel signalling Subsystem

Subsystem

MTS

Mobile Telephony Subsystem

NMS

Network Management Subsystem

STS

Statistical Subsystem

DTS

Data Transfer Subsystem

Figure 1.2

Examples of subsystems

AXE Survey

The subsystems are divided into function blocks. These consist of either one or
three function units. In the ﬁrst case, the one unit is a central software unit and in
the latter case the three units are a hardware unit, a regional software unit and a
central software unit. See Figure 1.3.

AXE

System Level 1

APZ

APT

System Level 2

CPS

MAS FMS

SSS

GSS

NMS

Subsystem

Function Block

CJU

LIC

LIR

LIU

Function Unit

Figure 1.3

The system structure of AXE

The regional processors (RP) control the hardware devices organised in a number
of extension modules (EM). The EM is a concept serving many purposes; it
appears as the smallest handling unit in the system and it also is the smallest part
that could be knocked out by a power failure. For example, one ETC-board or a
whole TSM-magazine including up to 16 boards can be seen as an EM. The
extension module bus (EMB) connects the EMs and the RPs. RPs always work in
pairs, equally sharing the load of the EMs. Should a fault occur in one of the two
RPs, the other can still control all extension modules on the EM bus.

The RPs connect to the central processor (CP) via the regional processor bus
(RPB). All central software, for both APT and APZ, executes in the CP, while all
regional software executes in the RPs.

Depending on the hardware conﬁguration, different RP types control the hard
ware in the extension modules. See Figure 1.4.

•

The RP is the classic regional processor controlling most equipment except
radio base stations (RBS) and I/O-devices.

•

In the central subscriber switch (CSS), a regional processor bus converter
(RPBC) replaces the RP.

•

In the remote subscriber switch (RSS), the RPBC is replaced by a signalling
terminal central (STC) and a signalling terminal remote (STR) to realize sig
nalling towards the remote location.

•

The regional processors in RSS and CSS are called EMRPs. EMRPs are part
of the equipment in the application magazines (e.g. Line Switch Modules). A

Plex-C 1

magazine internal bus provides communication between EMRPs and appli
cation hardware.

•

Regional Processor Digital (RPD) is the unit receiving and sending signals to
or from the Transmission Radio Interface (TRI). The application hardware
(Transceiver Handler) is directly connected to the RPD internal bus, there is
no EM bus. In addition, there is no duplication of RPDs, only one RPD con
trols the application hardware.

•

All the I/O-devices, e.g., terminals, printers, or ﬂexible disks, connect to a
support processor (SP). The SP replaces the RP. The SP connects to the RP
bus using a regional processor adapter (RPA). The RPA translates CP mes
sages into SP statements.

RPBC

STC

I/O

STR

EMRPB

EMB

RPB

Extension Module

EMB

Extension Module Bus

EMRPB

Extension Module Regional Processor Bus

Regional Processor

Regional Processor Adapter

RPB

Regional Processor Bus

RPBC

STC

STR

RPD

Regional Processor Digital

TRH

EMRP

SSS/CSS

SSS/RSS

I/O system

BSC

TRH

RPD

RPA

Regional Processor Bus Converter

Support Processor

Signalling Terminal Central

Signalling Terminal Remote

Transceiver Handler

Figure 1.4

Different hardware conﬁgurations

AXE Survey

AXE Programming Languages

AXE software uses two types of programming languages: assembly languages
and high-level languages.

An assembly language works very close to the processor. Each instruction
usually corresponds to a single machine instruction, which means that the assem
bly language depends on the type of processor. Accordingly, the programmer
needs a detailed understanding of the computer. The main advantage of assembly
programs is that they may execute faster, if an experienced assembler program
mer writes optimized code.

High-level languages use general statements that translate or compile into several
assembly instructions. The assembly instructions then translate into machine
instructions. It is not necessary to know details about the target processor; high-
level statements are common for several processors. The disadvantage is that exe
cution may be slower. See Figure 1.5.

Compiling

CRESULT = CNUM + CCOUNTER;

ASA 210C:

RSA

AR0 - CNUM;

RSA

AR1 - CCOUNTER;

AR0 - AR1;

WSA

CRESULT - AR0;

0111 1000 0110 0001

0111 1100 1001 0001

0000 0000 0001 1110 0001 1111 0101 1111

0111 1001 0100 0010

Assembling

High-Level Language

Plex code:

Assembly Language

Machine Code

Figure 1.5

Compiling and assembling

Plex-C 1

•

CP programs use the high-level language Plex-C. The compiler produces an
assembly language version of the program. This language is ASA 210C.
Some time–critical routines of the program may be written directly in ASA.

•

RP programs use assembler code, either ASA 210R (old programs) or ASA
21R.

•

EMRP programs use Plex-M, an 8-bit version of Plex. The compiler trans
lates Plex-M into the assembly language ASM6809 (by Motorola).

•

STR and STC programs are written directly in ASM6809 (by Motorola).

•

RPD and EMRPD programs, common in mobile telephony applications and
in RSS, use the high-level languages C and C++.

•

SP programs use ERIPASCAL, a real-time version of the high-level lan
guage PASCAL.

Figure 1.6 shows the hardware structure with the main programming languages.

STC

STR

ASM 6809

ASA 21R
ASA 210R

ASA 210C

ASM 6809

EMRP

ASM 6809

EMRPD

C/C++

RPD

RPA

Plex-C

ERIPASCAL

Plex-M

Figure 1.6

Programming languages used for the AXE processors

AXE Survey

AXE Central Processors

The central processor (CP) is the central control unit of the system, taking all
non-trivial decisions. Routine operations are performed by RPs relieving the CPs
of simple but time-consuming tasks.

The CP is always duplicated. The two sides, CP-A and CP-B, work in parallel,
performing exactly the same operations. During normal operation, the CP-A side
is executive and the CP-B side is on stand-by. A continuous check is made to
ensure that both processors reach the same results. If they do not, something is
wrong and several procedures start in order to overcome the fault.

The CPs store all central software and data. The CP memory consists of the regis
ter memory and the different stores. Programs are stored in the program store
(PS) and data is stored in the data store (DS). The reference store (RS) contains
information about where to ﬁnd the different programs and data. See Figure 1.7.

Data Store

Program Store

Reference Store

Figure 1.7

Stores in the central processor

Executing a program, the required data is transferred from the DS to the register
memory (RM), because arithmetic and other processor operators work on regis
ters only. The RM, shown in Figure 1.8, consists of several different registers
used for different purposes.

Depending on the processor type, each register is 16 or 32 bits in length. There
are four sets of 64 processor registers for the application programs, plus some
other registers. One set is reserved for fault-ﬁnding and tracing variables (TRL =
trace level). Telephone trafﬁc routines use the THL registers (THL = trafﬁc han
dling level). Input-output routines that have a lower priority use the CL registers
(CL = C level), while self-testing tasks have the lowest priority level and use the
DL register set (DL = D level).

Plex-C 1

PR0

PR1

SR0

SR1

DR0

DR1

DR2

DR23

AR0

AR1

AR2

AR3

WR0

WR1

WR2

|
|
|

WR29

|
|

TRL

THL

Figure 1.8

The processor registers in the register memory

IR:

The Index Register contains the current index for arrays (indexed varia
bles).

PR0:

Pointer Register PR0 contains the pointer value when addressing record
individuals.

PR1:

Pointer Register PR1 contains a pointer to a buffer variable in DS. It
also stores a variable during the ASA loop statement FESR.

CR:

The Compare Register is used when a comparing register values. The
CR stores one of these values.

SR:

The Signal Registers store signal information.

DR:

The Data Registers store signal data.

AR:

The Arithmetic Registers are mainly used in arithmetic and logic opera
tions.

WR:

The Working Registers store temporary data and intermediate results.

AXE Survey

Addressing Basics

Figure 1.9 shows the program store containing the object or machine code of the
program and information about the signals for the function blocks

➊

. The infor

mation needed for ﬁnding a program is the block number. The block number (

➋

in Figure 1.9) addresses administrative information in the reference store (RS).

In the RS, every block has its own area with eight words (four words in APZ
211). One of these words is the program start address (PSA)

➌

which contains

the address in the PS of where this program is stored

➍

. To ﬁnd a particular

sequence in the program, some signal information stored in the PS

➎

, is needed

as well. Chapter 6, Block Interaction, discusses these addressing procedures in
detail.

Program Store

Reference Store

Block Number

➋

➎

Block 5

PSA

➊

➍

PSA

➌

Figure 1.9

Addressing a program

The data store keeps the values of most variables, as shown in Figure 1.10. To
access a variable, the block number points to the relative address of the block in
the RS (

➊

in Figure 1.10). One of these relative addresses is the base start

address (BSA)

➋

. The BSA contains the address to a special area in the lower

part of the RS, the base address table

➌

The base address table stores the absolute address of each variable in the DS.
This address is the word address (WA). Chapter 5, Data Sector, discusses these
addressing procedures in more detail.

Plex-C 1

Reference Store

Data Store

Block Number

➊

Reference

Block 5

Table

BSA

➌

Block 5

Base Address
Table

BSA

➋

WA
WA

Figure 1.10

Addressing a variable

The addressing principles may seem very complicated, but they have obvious
advantages. A program can move to a new location in the PS without affecting
anything but the program start address. Likewise, the number of program varia
bles can change without affecting anything but the base address table.

Source System, Product Line,

and Application System

A source system is a structured group of products. The products ﬁt to each other
and new products can be added easily. AXE products include subsystems, blocks,
and units. There are separate APZ and APT source systems. Different applica
tions, for instance mobile telephony and ISDN, may share the same APT source
system. The APZ source system mainly depends on the APZ processor type. New
products and corrections are designed in a source system.
Examples: APZ 211 11 and APZ 212 20 are APZ source systems. APT 210 15
and APT 210 18 are APT source systems.

Ericsson delivers may different types of exchanges, for instance, local exchanges,
transit exchanges and mobile switching centres. The products for one type of
exchange based on one particular APT source system establish a product line. A
product line is a set of products from one source system that is designed for one
type of exchange. Example: MG/APT 210 15 is the product line for Mobile GSM
exchanges based on the APT 210 15 source system.

An application system is speciﬁc to a certain market or customer. An application
system consists of a subset of products from one APT product line and one APZ
source system. Example: AXE 105 09/17 is an application system for mobile
GSM exchanges using the APZ 212 20 control system.

AXE Survey

Market-dependent parameters, such as tone types for signalling, and printouts in
different languages, are not part of the program units or the source system. These
parameters, which differ from operator to operator, are written in a special docu
ment, the parameter list, which contains values for these market-dependent
parameters. The parameter lists are added in the application system.

Exchanges are created from the application system, with the local environment
taken into account. All exchanges in an application system share the same soft
ware. Individual exchanges may differ in hardware and exchange-dependent
parameters, such as subscriber data and routing information. These data have to
be added by means of commands.

Exchange

Application System

APT + APZ

Source System

APT

Product

Line

Source System

APZ

Market-dependent parameters

Exchange-dependent parameters

Figure 1.11

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

Plex-C 1

Chapter Summary

After reading this chapter, please remember:

•

Plex is an acronym of Programming Language for EXchanges. It is a high-
level language used in the central processor in AXE

•

AXE, system level 1, is divided into system level 2, subsystems, function
blocks, and function units

•

the hardware conﬁguration includes a central processor, regional processors,
extension modules and hardware devices

•

the difference between a high-level and an assembly language

•

the purpose of program store, reference store and data store

•

differences between source system, product line and application system.

Chapter 2

Documents

Introduction

AXE software production involves several documents. This chapter describes the
contents of the most important software (SW) documents and shows how these
documents compile into the binary object code.

Chapter Objectives

After completing this chapter, you are familiar with:

• document numbers and revisions for software documents

• the contents of these software documents:

−

Source Program Information

−

Source Parameter List

−

Parameter List

−

Signal Description

−

Signal Survey

• the contents of the ID sector

• the compilation and object generation processes

Figure 2.1

Chapter Objectives

Document Numbers

Every year, Ericsson staff produce thousands of documents. Identifying these
documents with unique numbers is essential. Therefore, this chapter brieﬂy dis
cusses numbering of SW documents before looking at the documents themselves.

Consider this document id: 190 55-CAA 107 1918 Rev. B. The following parts
identify a document:

•

190 55

the decimal class

identifying the document type

•

CAA 107 1918 the product number identifying the product

•

Rev. B

the revision

identifying the version of the document

The document number includes the decimal class and the product number. The
document id includes the document number and the document revision. The revi
sion is essential to identify the right version of a document.

Plex-C 1

Figure 2.2 shows decimal classes for some software documents.

190 55

Source Program Information

155 14

Signal Survey

190 59

Parameter List

190 73

Source Parameter List

n/155 14

Signal Description

Figure 2.2

Decimal classes of software documents

Each product receives a unique number consisting of some letters, the ABC class,
and a 3 to 7 digit number. The ABC class determines the product’s place in the
AXE hierarchy. For example, the ABC class of a software unit is CAA, in both
APT and APZ.

ABC

Class

AXE

ABC

Class

AXE

System Level 1

ANZ

CAA

CPS

APZ

CNZ

Subsystem

Function Unit

APT

ANT

CNT

CAA

LIR

CJU

LIU

APT

APZ

KR LI

SSS

System Level 2

Function Block

MAS FMS

GSS NMS

Figure 2.3

ABC classes and the system structure

The ABC class is followed by several digits building the product number. The
following rules apply.

System level 1 has the ABC class AXE and the product numbers AXE 105 for
traditional AXE systems and AXE 106 for systems using the Application Modu
larity architecture.

Documents

System level 2 has different product numbers for APT and APZ systems, typical
examples include APT 210 15 or APZ 212 30.

Subsystems have numbers such as ANT 217 01, where 217 identiﬁes the subsys
tem and 01 the version of the subsystem.

Function blocks use the consecutive number for the subsystem followed by a
number for the block. For instance, CNT 217 1234 identiﬁes block 1234 in sub
system 217.

Software function units have different number series for CP, RP, and EMRP.

CP:

CAA 107 3456
CAAZ 107 3456 (exception)
CAAU 107 3456 (unit speciﬁc for US market)
CAAP 107 3456 (unit speciﬁc for Australian market)

RP:

CAA 105 3456

EMRP:

CAA 117 3456

where 3456 is a consecutive number.

Note: the number serial CAAZ 107 ... is only used, if the ordinary number
sequence CAA 107 ... ran out of numbers.

Special rules apply for signal descriptions. Block-internal signals use block prod
uct numbers. Signals sent between blocks in one subsystem, for example KR and
LI, use subsystem product numbers.

Consider these examples.

Document Number

Document Type

190 55 - CAA 107 4567

SPI, Plex-C program for CP unit CAA 107 4567

155 14 - CAA 107 4242

Signal survey for unit CAA 107 4242

5/155 14 - CNT 219 1619

Signal description for a block internal signal

42/155 14 - ANT 219 07

Signal description for a signal sent between
blocks of the same subsystem ANT 219 07

Table 2.1

Sample document numbers

The revision identiﬁes the version of the document. During the design work,
designers use preliminary revisions (PA1, PA2, PA3, ..., PB1, PB2, ..., PC1, ...).
When the document has been successfully checked and approved, the document
receives a ﬁnal revision such as A or B. The available letters include A to Z,
excluding I, O, P, Q, R, U and W. If revision Z is not sufﬁcient, two-letter revi
sions apply (AA, AB, AC, ... , AZ, BA, ... , ZZ).

Example 1

A designer needs to update the approved document
190 55 - CAA 107 4284 Revision B.

Plex-C 1

The designer immediately changes the revision to
190 55 - CAA 107 4284 Revision PC1
at the beginning of the design activities to indicate that the document is no longer
in an approved state.

Software Documents

All CP software documents follow the Plex-C syntax rules. All these documents
need an identity sector at the end of the document.

Identity Sector

The identity sector contains the document number, the revision, the designer's
signature, and the codes for the department responsible for the document, and the
approving department. shows the identity sector for the source program of the
CP SW unit KR2U.

Example 2

ID KR2UPROGRAM TYPE DOCUMENT;

CLA 19055;

NUM CAA 107 7890;

REV C;

DAT 95-05-19;

DES ETX/PN/CDD SBRT;

RES ETX/PN/CDD;

APP ETX/PN/CDD;

END ID;

Figure 2.4

A typical ID sector

•

CLA decimal class, here 190 55 for source program information.

•

NUM product number, here CAA 107 for central software units and consec

utive number 7890.

•

REV document revision, here C.

•

DAT date of last modiﬁcation, here May 19, 1995.

•

DES department and signature of the designer, Steffen Bretzke.

•

RES department responsible for the technical content.

•

APP department that has approved the document.

Documents

Document Types

This section deals with the contents of ﬁve different Plex-C documents, namely:

•

SPI

Source Program Information 190 55

•

SPL Source Parameter List

190 73

•

Parameter List

190 59

•

Signal Survey

155 14

•

Signal Description

n/155 14

Note: the statements in this chapter are based on the Rationalised Software Pro
duction (RSP) concept. The APZ P2 project introduced RSP in 1993/4.

Source Program Information (SPI)

The SPI contains the program or source code itself. The central processor exe
cutes the statements in the SPI (after compilation). The SPI uses Plex-C, but may
include ASA assembler sectors. There is one SPI per software unit.

Parameter List (PL)

Many different markets and application systems share the same software units.
The PL document modiﬁes the standard code to local markets using market-spe-
ciﬁc parameters. For example, the PL deﬁnes printouts in the local language, tone
types, and charging parameters. This avoids frequent modiﬁcations of the source
code itself.

The PL is usually written by the local support organisation and not the unit
designer. There is one PL per software unit and application system (market).

Source Parameter List (SPL)

The source parameter list contains default values for all data in the PL document.
SPL and PL look almost identical. The unit designer creates the SPL, one per SW
unit, and the local support organisation adapts the market-speciﬁc parameters to
local values.

The program production process does not use the SPL directly, see Figure 2.5.
Instead, the process uses a generic PL which is identical to the SPL except for the
document name and number.

Signal Description (SD)

The function blocks and units communicate with signals. The SD describes the
purpose, type and data of one signal. SDs are stored in separate signal handling
libraries accessible from the SIGMA database on IBM mainframe systems.

Some CP SW units use local or unit-internal signals. These signals have a brief
SD which is included in the SPI for the SW unit.

Plex-C 1

Signal Survey (SS)

The SS is a list of all the different signals that one function unit receives and
sends. There is one SS per function block.

This book mainly presents information about the SPI. However, Chapter 3,
Declare Sector, discusses PL and SPL documents. Chapter 6, Block Interaction,
discusses SD and SS documents.

From Plex to Object Code

This section covers the processes and documents needed to produce the machine
code following the rationalized software production concept.

Rationalized software production contains three processes:

•

Code Generation

•

Object1 Process

•

Object2 Process

Code Generation is the compilation process with the Source Program Informa-
tion (SPI), the Signal Descriptions (SD), and the Signal Survey (SS) as input doc-
uments. Code Generation will produce code in machine language as well as the
Program Information ﬁle with the ASA 210 C assembler code.

The exchange can read the generated machine code, but it is like a Swiss cheese:
there are lots of holes and omissions in it. The missing pieces are ﬁlled in in the
Object2 Process, before loading the program in an AXE exchange.

The Object1 Process generates the Signal Distribution Data. The process uses the
Code Generation Result and the Signal Survey (SS) documents as input.

The Signal Distribution Data include printouts of the software unit document sur-
veys, the initial data list, the DS constants and local symbol values, as well as the
Signal Distribution and the Signal Sending Table for each block. Chapter 6, Block
Interaction, discusses these tables.

The Object2 Process is the ﬁnal process in program production. The process ﬁlls
the holes in the Swiss cheese, that is, the output of the Code Generation process.

•

actual values for market-dependent parameters, taken from the Parameter
List

•

unique block numbers for all blocks, taken from the block allocation table
(BAT ﬁle), which is not discussed in this book

Code Generation

Object1 Process

Object2 Process

Documents

The Object2 Process results in a unique, ﬁnal target code, the Object ﬁle. The
process generates one binary ﬁle for each SW unit. The exchange loads all these
ﬁles from the Reference Generation Tape, which contains the complete binary
code. Figure 2.5 shows the entire process.

Figure 2.5

Survey of program production (with RSP)

Source Progr.
Information

Signal
Description

Signal
Survey

Source Para-
meter List

Signal Distri-
bution Data

Block Alloctn.
Table docum.

rogram

nfor-

mation

ASA

Object File

Code Gene-
ration Result

Parameter
List

Code Generation

Object1 Process

Object2 Process

Reference Generation
Tape

Plex-C 1

Analysing Documents

Before compiling the Plex-C documents for program production (SPI, SS, SD,
PL), the documents have to be analysed. Analysing a document includes a check
of the Plex-C syntax. The output of the analysis process is an analysed source
document free of comments and other redundant information.

The analysis does not produce any kind of assembler code, though; the output is
still a Plex document. Table 2.2 shows the different document types and their ﬁle
extensions in UNIX.

Abb.

Document type

decimal class

original ﬁle

extension

analysed ﬁle

extension

SPI

Source Program
Information

190 55

.program

.anapgm

Signal Survey

155 14

.ssurv

.anasurv

Signal Description

n/155 14

.signal

.anasig

SPL

Source Parameter List

190 73

.sparam

–

Parameter List

190 59

.param

.anapar

Table 2.2

Document types and UNIX ﬁle extensions

Note that it is not necessary to analyse the SPL, because the program production
processes do not directly use the SPL.

Documents

Figure 2.6

Analysing the source program information

The SPI can be analysed on its own, in which case the Analyzetool runs the regu-
lar syntax check. However, the Analyzetool can do much more. Include the ana-
lysed signal survey and libraries of analysed signal descriptions when analysing
the SPI, and the tool can fetch the signal from the libraries.
Then the Analyzetool can check that signal name, number and type match
between the documents.

The output from this analysis process includes three ﬁles:

•

a listing ﬁle

ﬁle extension .listpgm

•

an analysed program

ﬁle extension .anapgm

•

a diagnostic ﬁle

ﬁle extension .diagpgm

The listing ﬁle contains a formatted printout of the program including some sta-
tistics, error and warning messages. This ﬁle is part of the E-module (a binder
containing all the information about software units for SW testers).

The diagnostic ﬁle contains the error and warning messages in an unreadable
form.

The analysed program is the main output. It is the basis for the next step, code
generation, described on page 18.

Analyse

Object1 Process

Analyse

Code Generation

Signal Survey

.ssurv

Source Program Information

Signal Descriptions

.signal

.anasig

.listpgm

.diagpgm

.anasurv

.anapgm

.program

Analyse

Object2 Process

Plex-C 1

Basic Test

The software and hardware need to be tested. The testing comprises four stages:
the basic test, the joint test, the function test and the system test. The system test
is also known as the integration test.

Design

Testing

System Design

Function Leve

System Level

System Test

Function Design

Function Test

Block Design

Block Level

Joint Test

Unit Design and ...

Unit Level

... Basic Test

Figure 2.7

Top-down design and bottom-up testing

The unit designer performs only one of these four tests, namely the basic test.
Testers take care of joint test, function test and system test. When delivering the
exchange, installation testers check the complete system one last time. This check
is the installation test.

The purpose of the basic test is to test the internal logic in the software unit. The
designer checks each code statement. The basic test has two stages:

•

desk check

•

emulator test.

The desk check is performed by an experienced designer who carefully reads and
checks your program for layout and logic problems. The purpose of the desk
check is to ensure that:

•

all documents are as easy to read as possible

•

the data structure is accurate and efﬁcient

•

the naming conventions of constants, variables, labels, etc., have been fol
lowed

Documents

•

signals and signal data agree with the signal descriptions

•

the program follows applicable design rules

The emulator test uses the APZ emulator or EmuTool. This tool emulates the
entire APZ including the central processor. The EmuTool uses binary code as
input. To execute an emulator test, you need a compiled dump ﬁle with the binary
code for all blocks involved. The EmuDumpGenTool assists you in creating a
dump ﬁle.

The emulator test is mandatory for verifying size alteration and start/restart rou
tines in your program (these routines are discussed in the course Plex-C 2). It is
also used to test I/O handling, commands, and block interaction.

The joint test is performed for all blocks that include hardware. In the joint test,
the software and the hardware units in one block are tested together.

The function test is executed in a system test plant using real object code gener
ated in program production. The tester issues commands and tries to make tele
phone calls verifying that the speciﬁcations at the function level are accurate.

The system test is also executed on a system test plant. The tester checks that all
parts and functions of the exchange operate successfully with each other.

Chapter Summary

This chapter discussed the documents used in software production, namely:

•

Source Program Information (SPI)

•

Signal Description (SD)

•

Signal Survey (SS)

•

Source Parameter List (SPL)

•

and Parameter List (PL)

The chapter also covered document numbers and revisions. Remember that pro
gram production consists of compilation and object processes. Finally, remember
the different types of test activities.

Plex-C 1

Chapter 3

Declare Sector

Introduction

A Plex document consists of four parts: a declare sector, a program sector, a data
sector, and an ID sector. The declare sector contains variable and constant decla
rations. This chapter describes the most common statements for declarations.

Chapter Objectives

After completing this chapter, you are:

• able to describe the contents of the declare sector, program sector

and data sector

• able to read the metasyntax used in the Plex-C language descrip

tion

• able to use and declare

−

variables

−

structures

−

records, ﬁles and pointers

−

symbols

Figure 3.1

Chapter Objectives

Introduction to Plex

Just as spoken languages follow certain grammatical rules, a programming lan
guage must follow a deﬁned syntax. The compiler translates the programming
statements into processor commands. Syntax rules ensure that designers only
write statements which the compiler accepts. In addition to the syntax rules, there
is a large number of design rules which describe how to write effective and efﬁ
cient code. Design rules are frequently updated. The DRtool, which is part of
APStools, provides easy access to all valid design rules.

Two design rules state the basic principles of Plex-C programming.

•

Create programs which are easy to read and document the code with many
comments. Simple and clear solutions are preferable to smart ones.

•

Data memory is cheap, but execution time is precious. Optimise your SW
units for speed, not for minimal data structures.

Plex-C 1

A Plex-C Program

The source program information (SPI) for one function unit consists of four
parts: the declare sector, the program sector, the data sector, and the ID sector.
See Example 3.

To improve readability, use a standard set of headings when writing an SPI. The
document instruction for the SPI lists and discusses these headings. Put titles and
headings in comments, Plex-C indicates comments with exclamation marks (!).

Example 3

This example shows the four parts of a Plex program for the software unit KRU.

DOCUMENT KRUPROGRAM;

DECLARE;

END DECLARE;

PROGRAM; PLEX;

END PROGRAM;

DATA;

END DATA;

END DOCUMENT;

ID KRUPROGRAM TYPE DOCUMENT;

CLA 19055;

NUM CAA 107 1234;

REV A;

DAT 95-05-06;

DES ETX/TK/D ERST;

RES ETX/TK/D;

APP ETX/TK/D;

END ID;

Figure 3.2

General Structure of a Plex-C Program

In the declare sector, declare variables, constants, records, pointers, etc. The pro
gram sector contains the executable statements.There may be more than one pro
gram sector in a document, i.e., one written in Plex and one or more written in
ASA. Finally, in the data sector set initial values for variables and ﬁle sizes that
are only valid when the program is loaded into the exchange. The data sector also
contains allocations of variables to relative addresses in the reference store. The

Declare Sector

SPI ends with an identity sector described in Chapter 2, Documents. The ID sec
tor follows after END DOCUMENT.

Some SPIs include additional sectors; see page 141 for the Signal Sector and
page 222 for the Parameter Sector.

A source program in Plex consists of several statements; statements terminate
with a semicolon (;). Make the program easy to read and understand, so start each
new statement on a new line. Please note that statements can continue over an
arbitrary number of lines. Furthermore, spaces and empty lines, which can be
inserted anywhere in the program, should be used frequently and make the pro
gram easy to read. Comments, which are not translated by the compiler, must
start and end with an exclamation mark (!).

System-Deﬁned Characters

All characters in Plex follow the ISO CCITT No. 5 character set which uses
seven binary digits to code one character. The ISO code is shown in Figure 3.3.
Since Plex uses a 16-bit processor, the system reserves eight bits or one half-word
for all letters and special characters.

0
0
0

0
0
1

0
1
0

0
1
1

1
0
0

1
0
1

1
1
0

1
1
1

0 0 0 0

NUL

DLE

0 0 0 1

SOH

0 0 1 0

STX

0 0 1 1

ETX

0 1 0 0

0 1 0 1

ENQ

NAK

0 1 1 0

SYN

0 1 1 1

BEL

ETB

‘

1 0 0 0

CAN

(

1 0 0 1

)

1 0 1 0

SUB

1 0 1 1

ESC

;

1 1 0 0

1 1 0 1

1 1 1 0

1 1 1 1

DEL

ISO Code (CCITT No. 5)

EOT

ACK

Figure 3.3

The ISO code CCITT No. 5

Plex programs consist of a speciﬁed set of characters only:

Plex-C 1

Letters (capitals) A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Decimal digits

0 1 2 3 4 5 6 7 8 9

Editing characters LF (Line Feed)

SP (SPace)

Special characters "

quotation mark

hash

ampersand

single quote

exclamation mark

asterisk

plus

comma

–

minus, dash

dot

slash

colon

;

semi-colon

equals

question mark

underscore

[ ]

opening/closing brackets

caret

( )

opening/closing parentheses

Special characters may not appear in names of variables or labels.

The ISO codes #24 ($), #7F (DEL) and #08 (BS) are reserved for editing input
data. The ISO codes #5B(Ä), #5C (Ö), and #5D (Å) correspond to characters in
national (Swedish) use, do not use them in regular programs.

Metasyntax

This book follows this syntax:

Key words, i.e., system-deﬁned words, print in BOLD CAPITALS.

Non-system words, that is, names of variables and words that are replaced with
numbers, print in lower case italics.

[A]

indicates that A is optional.

indicates to use one, and only one, of the elements in braces.

[A]1...

indicates to use element A in the brackets at least once. Repeat A as
often as necessary. Separate all As by commas (,).

Variable Declarations

A variable is just a speciﬁc part of the memory that contains a combination of
ones and zeros. Variables simplify addressing to this memory area. When a varia
ble name is assigned to a speciﬁc area of the data store, there is no need to know
the computer's internal addressing principles to access this area; it is sufﬁcient to
know the variable name.

Declare Sector

In Plex, variables names start with a letter and consist of uppercase letters and
numbers only. It is not possible to use special characters or lowercase letters. Var
iable names may be up to 50 characters long.

Declaring a variable ensures that the proper amount of memory is reserved for it
in the data store or the register memory. In Plex, each variable must be declared in
the declare sector. A variable always belongs to one CP software unit and can
never be accessed directly from another CP unit. The only exception are buffer
variables, see page 197, and the new AXE Parameters, see page 219.

The value range of a variable depends on the size of the data area reserved for it
in the variable declaration.

Variables can be stored or temporary:

•

The value of a stored variable is stored in the data store. It is loaded into a
register in the register memory (RM) for processing, and then written back
into the data store. Thus, the value of a stored variable is never lost, even if
the program is exited and re-entered later.

•

The value of a temporary variable exists only in a register in the RM and
only while its software unit is being executed in the CP. As soon as that pro
gram exits the CP, the value of the temporary variable is lost. Temporary var
iables are much faster to access, because they do not have to be fetched from
and written to the data store.

There are three different data types:

Field variables

store numeric information in binary form. They contain non

negative integers only. They can be temporary or stored.

Symbol variables

store symbol information as symbol values, e.g., idle,

busy, blocked, false, true. They are also known as enumeration type varia
bles. Symbol variables can be temporary or stored.

String variables

store text strings as a number of alphanumeric characters.

They are always stored.

Stored variables may be assigned different properties: DS, CLEAR, RELOAD,
DUMP, STATIC, BUFFER, and COMMUNICATION BUFFER. These proper
ties relate to the mode of storage and the way the variable is treated at start and
restart.

From a storage point of view, the variables can be divided into the following
types:

T emporar y

Stored temporarily in a register, often a working register.

Permanently stored in DS, temporarily loaded into register memory.

COMMUNICA TION B UFFER and B UFFER

Stored in a dynamically allo

cated buffer. The variable uses almost no space in the data store until mem
ory in the DS is allocated by a command. Chapter 9, Buffers and
Structures, discusses these data types in detail.

Plex-C 1

Normally, the exchange starts the software and it never stops. After serious
errors, however, the APZ stops the program execution and restarts the software.
The following properties describe the variable behaviour at start or restart:

CLEAR

Clearing at start/restart.

Field variables are set to zero; symbol variables to the ﬁrst value in their
declaration list.

RELOAD

Loading at ‘restart with reload’.

The variable value is reloaded from tape/hard disk to ensure that the values
before and after the ‘restart with reload’ are the same.

DUMP

Dumping at restart.

For testing and tracing purposes, the variable value is written to a special
dump ﬁle before a restart. It is printed in the restart printout.

When operators need to update a software unit in an operating exchange, they
order a function change. A function change replaces one or more software units
by updated versions without stopping the exchange. For this situation, a variable
may have the following property:

STATIC

Value not transferred between old and new software versions.

Normally, the variable values are copied from the old software unit version
to the new software unit version to ensure the uninterrupted execution of
the programs. STATIC variables are exempt from this procedure.

Not all combinations of the variable properties are possible. For example, a varia
ble cannot have the properties DS and BUFFER at the same time. The Plex-C
Language Description contains a table listing all valid combinations.

Field Variables

Field variables store positive integers in binary form. The numeric value of such a
variable can vary from 0 to 2

-1, where n is the length of the variable in number

of bits. The variable length should be stated, otherwise it defaults to 16 bits.

Note that variable names may only consist of letters and digits. Special characters
are not permitted. Declare ﬁeld variables in the following way:

Declare Sector

VARIABLE

name [length] [properties]

;

name = Name of variable. Names for temporary variables should start with the
letter T (temporary) and those for stored (except individual) variables with the let
ter C (common).

length = Length of variable in number of bits which must be expressed as a num
ber that is a power of two, i.e. 1, 2, 4, 8, 16, 32, 64, 128. A ﬁeld variable cannot be
longer than 128 bits, and if it is more than 16 bits, it must be structured. If no
length is speciﬁed, the compiler assigns the variable length 16 bits. Temporary
variables may only be 16 bits in length.

properties = A valid combination of DS, BUFFER, CLEAR, RELOAD, DUMP,
STATIC. If properties are omitted, the variable is temporary.

Figure 3.4

Syntax for Field Variable Declaration

Example 4

The following example declares the temporary variable TCOUNTER consisting
of 16 bits, and the 4-bit stored variable CCLOCK.

VARIABLE TCOUNTER;

VARIABLE CCLOCK 4 DS;

Figure 3.5

Declaration of ﬁeld variables

CCLOCK stores values between 0 and 15, while TCOUNTER stores values
between 0 and 65535.

R Variables

Ericsson introduced a new variable category, R, to adapt the variable length to the
actual capacity and register length of the exchange.

Exchanges using a 16 bit processor such as the APZ 211 11 can handle up to
64k = 65,535 = 2

– 1 lines or subscribers, while exchanges equipped with

a 32 bit processor such as the APZ 212 11 could handle up to
4000M = 4,294,967,295 = 2

– 1 lines or subscribers. However, APZ 212 proc

essors only reserve 20 bits for R variables today, because there is no demand for
exchanges handling more than 1 million lines or subscribers. The 20-bit-limit
may change in the future without further notice.

Declare R ﬁeld variables in the following way:

Plex-C 1

VARIABLE

name R [properties]

;

name = Name of variable. Names for temporary variables should start with the
letter T (temporary) and those for stored (except individual) variables with the let
ter C (common).

R = The length of the R variable will depend on the target processor. If the block
containing the variable is loaded into the APZ 211, the length will be 16 bits. If
the block is loaded into a 32 bit APZ 212, the length will be 32 bits.

properties = A valid combination of DS, BUFFER, CLEAR, RELOAD, DUMP,
STATIC. If properties are omitted, the variable is temporary.

Figure 3.6

Syntax for R variable declaration

Please note the following limitations:

•

It is not possible to predict the maximum value or value range of an R varia
ble during software design.

•

R variables cannot be structured or be part of a structured variable.

•

R variables cannot be used as an index for an array.

Example 5

This example declares the temporary variable TINDNUM and the stored variable
CINDNUM.

VARIABLE TINDNUM R;

VARIABLE CINDNUM R DS;

Figure 3.7

Declaration of R variables

The value range of both variables is not known during unit design, since it
depends on the register size of the target processor.

One-Dimensional Arrays

A one-dimensional array consists of a number of identical parts, i.e., elements.
Plex allows integer arrays only, not string or symbol arrays. Address an element
in the array by the name of the array and an index in parentheses. The index indi
cates the number of the element in the array, starting from zero. Arrays are
always stored in the data store. They are also known as single indexed, stored
ﬁeld variables. Declare arrays this way:

Declare Sector

VARIABLE

name

(

index size

)

[length] properties

;

name = Name of variable. Names for stored variables (except individual vari
ables) should start with the letter C (common).

index size = The number of elements in the array, which can assume any value up
to a target-machine-dependent maximum value (32K in APZ 212 20). For some
target machines, the index size is increased to the nearest greater power of two.

length = The number of bits of each element, which can be 1, 2, 4, 8, 16, 32, 64,
128. If the size of the elements is register dependent, the length should be speci
ﬁed as R. If no length is speciﬁed, the compiler assigns the value 16 bits. Ele
ments longer than 16 bits must be structured. However, R array elements may not
be structured.

properties = A valid combination of DS, RELOAD, CLEAR, DUMP, STATIC.

Figure 3.8

Syntax for one-dimensional array declaration

Example 6

This example declares the array CNUMBER, see Figure 3.9.

CNUMBER (15)

CNUMBER (0)

CNUMBER (1) CNUMBER (2)

Figure 3.9

The array CNUMBER

VARIABLE CNUMBER (16) 4 DS;

Figure 3.10

Declaration of a one-dimensional array

CNUMBER is an array for storing a subscriber number of up to 16 digits. The
array consists of 16 elements of 4 bits each. Four bits are required to store one
digit of a number (2

– 1 = 15). Please note that the index 16 in the declaration

states how many elements the array contains. Since the numbering starts at 0, the
last element is, consequently, CNUMBER (15).

Plex-C 1

Two-Dimensional Arrays

A two-dimensional array, a matrix, consists of a number of identical parts, called
elements. Two array indices address a matrix element. These indices indicate the
numbers of the row and the column. The numbering starts at zero. Two-dimen-
sional arrays are also known as double indexed, stored ﬁeld variables.

VARIABLE

name

(

rows, columns

)

[length] properties

;

name = Name of array. Names for stored variables should start with the letter C.

rows = The number of rows in the array can assume all values from 2 up to a tar-
get-machine-dependent maximum value. For some machines it will be increased to
the nearest power of 2.

columns = The number of columns, which can assume the following values: 1, 2, 4,
8, 16, 32, 64, 128, up to a target-machine-dependent maximum value.

length = The number of bits of each element, which can be 1, 2, 4, 8, 16, 32, 64,
128. If the size of the elements is register-dependent, set the length to R. If no length
is speciﬁed, the compiler assigns 16 bits. Structure elements longer than 16 bits.

properties = A valid combination of DS, CLEAR, RELOAD, DUMP, STATIC.

Figure 3.11

Syntax for two-dimensional array declaration

Example 7

This example declares array CCOUNTER.

CCOUNTER (0,7)

CCOUNTER (0,0) CCOUNTER (0,1)

CCOUNTER (2,1)

CCOUNTER (3,7)

Figure 3.12

The two-dimensional array CNUMBER with 32 elements

Declare Sector

CCOUNTER has 4 rows and 8 columns, a total of 32 elements. Each element
consists of 4 bits.

VARIABLE CCOUNTER (4,8) 4 DS;

Figure 3.13

Declaration of a two-dimensional array

Symbol Variables

Symbol variables simplify the handling of symbol values. Some examples of
symbol values are: false, true, idle, blocked and busy. Symbol variables are
known as enumeration type variables in other programming languages.

Code generation replaces the symbol values with numeric values; however, the
programmer does not have to bother about this when writing programs. The use
of symbol variables makes programs easier to read and understand.

The numeric values assigned in the code generation correspond to the order of the
symbol values in the symbol value list. Thus, the ﬁrst value in the list receives the
numeric value 0, the second value receives the numeric value 1, etc. Symbol vari
ables always have a length of 16 bits. Consequently, the maximum number of
symbol values for one variable is 65535.

1...

SYMBOL VARIABLE

name =

(

[symbol value]

)

[properties]

;

name = Name of symbol variable. Names for temporary variables start with the
letter T (temporary) and the ones for stored (except individual) variables with the
letter C (common).

symbol value = Name of the symbolic value that the variable may take.

properties = A valid combination of DS, CLEAR, DUMP, RELOAD, STATIC. If
properties are omitted, the variable is temporary.

Figure 3.14

Syntax for symbol variable declaration

Example 8

This example declares the variable CSTATE with the possible values IDLE,
BUSY and BLOCKED. CSTATE is a 16-bit stored variable.

Plex-C 1

SYMBOL VARIABLE CSTATE =

(IDLE,

BUSY,

BLOCKED) DS;

Figure 3.15

Declaration of a stored symbol variable

Example 9

This example declares TRESULT, a 16-bit temporary variable with the possible
values FALSE and TRUE.

SYMBOL VARIABLE TRESULT =

(FALSE,

TRUE);

Figure 3.16

Declaration of a temporary symbol variable

Please note some limitations on the use of symbol variables:

•

It is not possible to compare one symbol variable to another one in an IF
statement.

•

It is not possible to assign the value of one symbol variable to another one.

The reason for this is that code generation replaces the symbol values with
numeric values, as discussed above. Consequently, IF would compare two unpre
dictable numbers, which may lead to unexpected results.

Some older Plex programs declare symbol variables without a symbol value list.
Note that in all new design work, it is mandatory to declare symbol variables with
a symbol value list.

String Variables

String variables store alphanumeric information. Characters use the ISO CCITT
alphabet No. 5, reserving eight bits for each character. The declaration speciﬁes
the maximum number of characters in the string variable, but not more than 255
alphanumeric characters. The data store keeps string variables in a consecutive
sequence of half-words (usually one word is 16 bits).

Please note that string variables can not be temporary variables.

Declare Sector

STRING VARIABLE

name maxlength properties

;

name = Name of variable. Names for stored variables (except individual variables)
start with the letter C (common).

maxlength = Maximum numbers of characters. The number of characters has to be

a power of two minus one, 2

- 1, i.e., 1, 3, 7, 15, 31, 63, 127, 255. The reason is

that the ﬁrst half-word indicates the present number of characters in the variable.

properties = A valid combination of DS, RELOAD, DUMP, STATIC. The DS
property is mandatory, since string variables cannot be temporary.

Figure 3.17

Syntax for string variable declaration

Example 10

This example declares string variable CMONTH, shown in Figure 3.19.

STRING VARIABLE CMONTH 15 DS;

Figure 3.18

Declaration of a string variable

The declaration reserves 16 half-words, i.e., 16 times 8 bits, for the variable
CMONTH. If the program assigns the text string APRIL to the variable, e.g., with
the Plex statement

CMONTH = "APRIL"

, the reserved area in the data store

contains the numeral 5 in the ﬁrst half-word, the characters A to L in half-words
two to six, and undeﬁned values in the remaining ten half-words.

Plex-C 1

Figure 3.19

The string variable CMONTH with the value APRIL

Please note that strings begin and end with quotation marks ("") in all statements.

Variable Structures

Sometimes it may be useful to reference speciﬁc bits of a ﬁeld variable. There
fore, it is possible to break down ﬁeld variables into subvariables that allow refer
ence to selected bits. Subvariables, in turn, can be broken down once more.
Hence, it is possible to break down ﬁeld variables in a one- or two-level structure.
Subvariables can differ in size, unlike the elements of an indexed variable.

Subvariables can be of arbitrary length, up to 16 bits. They are always stored in
the DS. If some bits are not used on their own, mark them with a plus (+) in the
declaration. If a subvariable is broken down into one more level, declare the sec
ond level directly after the ﬁrst one. Structured variables are always stored varia
bles.

Figure 3.20 shows how to break down 16-bit variable CFRIENDS into the sub-
variables GIRLS and BOYS, consisting of 8 bits each.

Declare Sector

GIRLS

CFRIENDS

BOYS

Figure 3.20

The variable CFRIENDS broken down into BOYS and GIRLS

These two subvariables are broken down into one more level. GIRLS is broken
down into RACHEL, PHOEBE, and MONICA while BOYS is broken down into
CHANDLER, JOEY, ROSS, and GUNTHER.

The variables RACHEL, PHOEBE, MONICA and CHANDLER consist of 2 bits
each, while JOEY and ROSS have 1 bit each and GUNTHER has 3 bits, see Fig
ure 3.21.

Gunther

Ross

Phoebe

GIRLS

Rachel

Monica

Joey Chandler

BOYS

Figure 3.21

The structure of the subvariables GIRLS and BOYS

All subvariables start on an “even” boundary, i.e., one-bit variables can start any
where, two-bit variables start on bit 0, 2, 4, 6, 8, 10, 12 or 14, three- and four-bit
variables start on bit 0, 4, 8 or 12, ﬁve- to eight-bit variables on bit 0 or 8, and
ﬁnally nine- to sixteen bit variables can only start on bit 0. Note that this implies
that unused space may exist between the subvariables.

Plex-C 1

It is possible to declare different structures for the same variable. But if the same
subvariable name is used in several structures, it must have the same length and
starting position in all of these structures.

Variables with a ﬁxed size of more than 16 bits, called super-variables, must
always be broken down into smaller parts, either by indexing or by structuring.
Note, however, that R variables may not be structured.

1...

STRUCTURE

name1 = [level name2 length]

;

name1 = Name of ﬁeld variable to be broken down.

level = Structure level, 1 or 2.

name2 = Name of subvariable. Unused bits are marked with a plus (+).

length = Length of subvariable: 1, 2, 3, ..., 16 bits.

Figure 3.22

Syntax for structuring

Example 11

This example declares and structures the variable CFRIENDS, shown in Figure
3.20 and Figure 3.21.

VARIABLE CFRIENDS 16 DS;

....

STRUCTURE CFRIENDS =

1 GIRLS 8,

2 RACHEL 2,

2 PHOEBE 2,

2 MONICA 2,

2 + 2,

1 BOYS 8,

2 CHANDLER 2,

2 JOEY 1,

2 ROSS 1,

2 GUNTHER 3,

2 + 1;

Figure 3.23

Two level structure

Declare Sector

Please note that all variables start on an “even” boundary, that unused bits are
marked with a plus, and that the second level starts directly after the ﬁrst level.

Example 12

This example structures the variable ADMSTATE (administration state) shown in
Figure 3.24. ADMSTATE is common to many device-handling blocks. The varia
ble name does not start with the preﬁx letter C, since ADMSTATE is part of a
record (see page 42).

EMCON

TSCON

RCON

ADMSTATE

Figure 3.24

The variable ADMSTATE

If the ﬁrst bit is set to zero, this implies that the device is connected to an EM. If
the third bit equals zero, it implies that the device is connected to the time switch
and, ﬁnally, if the fourth bit is set to zero, it implies that the device is connected to
a route. The other bits do not have any special meaning.

If the ﬁeld variable ADMSTATE is equal to 0, then the device is connected to all
relevant components. If the value is greater than 0, at least one of the necessary
connections is missing.

VARIABLE ADMSTATE 8 DS RELOAD;

....

STRUCTURE ADMSTATE =!ADMINISTRATION DATA!

1 EMCON 1,!ZERO IF CONNECTED TO EM!

1 + 1,

1 TSCON 1,!ZERO IF CONNECTED TO TIME SWITCH!

1 RCON 1,!ZERO IF CONNECTED TO ROUTE!

1 + 4;

Figure 3.25

One level structure

The syntax for using subvariables in the program is: variable.subvariable.
Example:

ADMSTATE.EMCON = 1;

(device disconnected from EM)

Plex-C 1

Records

are a good way of structuring the data in a program. Records collect

all variables that describe properties of a group of items, for instance, calls or
subscribers.

Example: A typical exchange with 2000 subscribers has at least 2000 line inter
face circuits (LIC). CP software unit LIU administers these LICs. LIU needs to
have a picture of the current state of the LIC hardware. The unit uses 2000
records, one for each LIC, where all relevant information about the LICs is
stored. Each record must use the same set of variables, but the values of the vari
ables differ between records.

Record variables

may be stored ﬁeld, symbol or string variables (DS or

BUFFER). Variables in a record may be indexed or structured, but two-dimen-
sional arrays are not permitted. Variables in a record are called individual varia
bles, DS variables that are not part of a record are known as common variables.
Accordingly, names of individual variables should not have the preﬁx C (which
identiﬁes common variables) or any other preﬁx. Individual variables are unique
in the program, that is, different records cannot contain variables with the same
name.

Files

are sets of records, in our example 2000 LIC records. One ﬁle consists of

one or more records, all with the same individual variables.

Pointers

address the relevant record in a ﬁle. In Plex, pointers. are not more

than record numbers. The records in a ﬁle are numbered, and the value of the
pointer is the number of the current record. It is possible to declare more than one
pointer for one ﬁle.

A ﬁle is a set of one or more records that share the same pointers. The name of
the ﬁle is always the same as the name of the individual records. The initial
number of records in a ﬁle is indicated in the data sector.

The record declaration speciﬁes all variables to be included in the records in a
ﬁle. After the record, declare the pointer(s) associated with that record.

RECORD

record name;

[variable declaration]

0...

END RECORD;

POINTER

pointer name

(

record name

) [R];

record name = Name of record.

pointer name = Name of pointer. The name should end on the sufﬁx pointer, ptr or
p. Declare additional pointers with separate POINTER statements.

Figure 3.26

Syntax for record declaration

Declare Sector

Pointers are not temporary variables, but pointers behave like temporary varia
bles. In other words, a pointer may lose its value whenever the execution of the
software unit has terminated. Pointers are stored in the register memory. Their
length is 16 bits by default.

The variable property R allows the declaration of pointers whose length depends
on the register size of the target processor. For 32 bit processors the R-marked
pointer could hold values greater than 65535. Consequently, the corresponding
ﬁle could contain more than 65535 records (on APZ 212 processors).

Example 13

This example declares ﬁle and records LIDATA, shown in Figure 3.27.

SUBNUMBER

NAME

LIDATA

STATE

LIDATAPTR

Figure 3.27

The ﬁle LIDATA with the associated pointer LIDATAPTR.

The ﬁle LIDATA consists of n + 1 records and has one pointer, LIDATAPTR.
There are three variables in each record: SUBNUMBER, NAME, and STATE.

Plex-C 1

RECORD LIDATA;

VARIABLE SUBNUMBER (16) 4 DS RELOAD;

STRING VARIABLE NAME 31 DS RELOAD;

SYMBOL VARIABLE STATE = (IDLE,

BUSY,

ABL,

MBL) DS;

END RECORD;

POINTER LIDATAPTR (LIDATA);

Figure 3.28

Declaration of a record

Access

The program syntax for using variables in a record is:

[pointer name:] variable name
Example:

LIDATAPTR:STATE = BUSY;

Individuals

are records. It is common practice in AXE-speak to call a record

an individual. Please keep this in mind when reading input documents in design
work.

Symbol Declarations

Constants

make handling ﬁxed values easier and increase the readability of

the program. In Plex, constants may consist of numeric or alphanumeric informa
tion, such as time-out values for time supervision, printout texts, etc.

Rather than repeating the constant value whenever necessary, deﬁne and use con
stants. Constants are called ‘symbols’ in Plex. These symbols are declared in the
declare sector and used in the program and data sector. Try not to confuse sym
bols with the symbol variables on page 35.

If the value of a symbol has to be modiﬁed during software design, only the sym
bol declaration statement or the parameter list has to be changed, and the execut
able statements using the symbol remain untouched. The code generation and
object processes replace the symbols with their actual values.

There are two types of symbols: market-dependent, called global symbols; and
market-independent, called local symbols. Global symbols get their values from
the parameter list, while local symbols are assigned values in the declare sector.

Global Symbols

Global symbols are market-dependent. Examples of global symbols are printouts
in different languages, charging parameters, and block types.

Declare Sector

•

Global symbols are deﬁned in the parameter list. The PL assigns values to
the global symbols, see Example 16.

•

Global symbols are declared in the declare sector of the source program.
This makes sure the name of the symbol is known in the program and
reserves sufﬁcient space in the DS. See Example 14 and Example 15.

Remember that the PL ﬁlls the “holes in the Swiss cheese” in the object2 process
during program production; see page 18.

There are two kinds of global symbols: one for numeric information, called a glo
bal number symbol; and one for alphanumeric information, called a global string
symbol.

Number symbols always have 16 bits.

GLOBAL NSYMB

name

(

range

);

name = Name of symbol

range = Set of permitted values. The range can be indicated either by giving a
maximum value or two extreme values. A hexadecimal value are preceded by the
character #. The largest possible value is 65535.

Figure 3.29

Syntax for global number symbol declaration

Example 14

This example declares the global number symbols GAMMA and DELTA and
their value range. Place these statements in the declare sector of the SPI.

GLOBAL NSYMB GAMMA (#FF);

GLOBAL NSYMB DELTA (2-42);

Figure 3.30

Declaration of Global Number Symbols

GAMMA can vary between 0 and #FF = 255, while DELTA can vary between 2
and 42.

AXE Parameters

Global number symbols are about to disappear in new software design. AXE
Parameters, a new concept for market-speciﬁc data, will replace most global
number symbols in the future. Chapter 10, AXE Parameters on page 219 has
more details.

Plex-C 1

Global String Symbols

Global string symbols deﬁne all output texts. This way, a local Ericsson support
ofﬁce can translate all printout texts by modifying the parameter lists, and not the
source programs.

GLOBAL STRING

name

(

length

);

name = Name of symbol

length = maximum number of characters. The length must be expressed as 2

-1,

i.e., 1, 3, 7, 15, 31, 63, 127.

Figure 3.31

Syntax for global string symbol declaration

Example 15

This example declares the global string symbol NBLDEV. Place this statement in
the declare sector of the SPI.

GLOBAL STRING NBLDEV (31);

Figure 3.32

Declaration of a global string symbol

Adapt the string symbol NBLDEV to different markets by writing, for instance,

STRING NBLDEV = "NUMBER OF BLOCKED DEVICES"

for an English-speaking market and

STRING NBLDEV = "ANTAL BLOCKERADE ORGAN"

for a Swedish-speaking market, in the parameter list for the block.

Remember to specify the length of the string symbol with a good margin so that it
is sufﬁcient for all the different languages. Remember, too, that all strings begin
and end with quotation marks (" ").

While global symbols are declared in the declare sector of the SPI, they also have
to be deﬁned in the parameter list document.

Example 16

The following frame contains an excerpt from a parameter list assigning values to
the global symbols that were declared in the previous examples.

Declare Sector

NSYMB GAMMA = #A2;

NSYMB DELTA = 42;

STRING NBLDEV = "ANTAL BLOCKERADE ORGAN";

Figure 3.33

Deﬁnition of global number and string symbols

Local Symbols

Deﬁne local symbols for all market-independent constants. Contrary to the global
symbols, local symbols receive their values in the declare sector of the SPI. Local
number symbols store numeric information, and local string symbols store alpha
numeric information.

NSYMB

name = numeric value

;

name = Name of constant. Local symbols should start with the preﬁx letter Z.

numeric value = Numeric value that will replace the symbol in the code genera
tion, and which can be expressed decimally or hexadecimally. A hexadecimal
value must be preceded by the character #. The largest possible value is 65535.

Figure 3.34

Syntax for local number symbol declaration

Example 17

This example declares the local number symbols ZTIME and ZNONE.

NSYMB ZTIME = 250;

NSYMB ZNONE = #FFFF;

Figure 3.35

Declaration of local number symbols

ZTIME receives the decimal value 250 and ZNONE receives the hexadecimal
value FFFF, or decimal 65535.

Local String Symbols

Declare and deﬁne local string symbols in a similar way.

Plex-C 1

STRING

name = "text"

;

name = Name of symbol. Local symbols should start with the preﬁx letter Z.

text = Text string that will replace the symbol in the code generation.

Figure 3.36

Syntax for Local String Symbol Declaration

The use of local string symbols is not recommended. Local string symbols cannot
be adapted to the local language, because they receive their values in the SPI’s
declare sector and not in the parameter list document. This may conﬂict with the
requirements of some telecom operators.

Example 18

This examples declares the local string symbol ZHELLO.

STRING ZHELLO = "HEJ";

Figure 3.37

Declaration of a Local String Symbol

The object2 process replaces symbol ZHELLO with the string HEJ everywhere
in the program.

Chapter Summary

This chapter discussed the general structure of a Plex-C program and the different
statements in the declare sector for variables and symbols.

Variables may be temporary or stored. There are three different types of varia
bles: ﬁeld variables, symbol variables and string variables. Field variables may be
declared as one- or two-dimensional arrays and they may be broken down into
one or two levels. All variables, except two-dimensional arrays, may appear in a
record. The variables in a record are always stored. They are called individual
variables, in contrast to common variables.

Declare Sector

The following table lists possible combinations of common variable types. R
indicates an R variable.

Type

emporar

ointer

Stored/DS

Buff

Common

Individual

Field

non-indexed

✗

non-indexed

✗

1 dim array

✗

1 dim array

✗

2 dim array

✗

2 dim array

✗

String

✗

Symbol

✗

a. A buffer variable may be an individual or a common variable.
b. Array elements may be declared as R variables, but not the array index.
c. Array elements may be declared as R variables, but not the array indices.

Table 3.1

Possible Combinations of Plex-C data types

Constants are called symbols in Plex. There are two groups of symbols: market
independent, called local symbols, and market-dependent, called global symbols.
Global symbols receive their values in the parameter list document, while the
SPI’s declare sector declares their value ranges. Local symbols receive their
actual value in the declare sector. There are symbols for both numerals, called
number symbols, and text, called string symbols.

Writing the declare sector, follow this order of variables and constants, see Figure
3.38. Chapter 9, Buffers and Structures, and Chapter 10, AXE Parameters, add
further segments to the declare sector which do not appear in Figure 3.38.

Plex-C 1

DECLARE;

!GLOBAL SYMBOLS!

!LOCAL SYMBOLS!

!RECORDS!

!COMMON AND STORED VARIABLES!

!TEMPORARY VARIABLES!

!STRUCTURES!

END DECLARE;

Figure 3.38

The order of variables and constants in the declare sector.

Note that, according to this order, structured variables are declared in the section
"COMMON AND STORED VARIABLES". The deﬁnition of their structures,
though, is usually several pages further down in the section "STRUCTURES" in
the declare sector!

Declare buffer variables not part of a record in the section “COMMON AND
STORED VARIABLES”.

Please note that Chapter 9, Buffers and Structures, and Chapter 10, AXE Parame
ters, discuss additional data types.

References

Software Reliability Handbook,
EN/LZG 205 603,
© Ericsson Telecom AB 1998

Updating of Software Units with R Variables,
ETX 102 60 - 1060 Uen,
© Ericsson Telecom AB 1993
Note: This document contains an extensive list of limitations for using R varia
bles.

Implementing Greater Than 64 K Files in AXE,
ETX 102 60 - 1061 Uen,
© Ericsson Telecom AB, 1993

Chapter 4

Program Sector

Introduction

The previous chapter introduced the declare sector. This chapter explains some of
the statements used in the program sector and some programming concepts.

Chapter Objectives

After completing this chapter and the exercises you are able to:

• translate a basic ﬂow chart into a Plex-C program

• write Plex-C statements for:

−

variable assignments

−

jumps

−

selections

−

iterations

Figure 4.1

Chapter Objectives

Programming Concepts

This section discusses program structures, operators and the concept of a ﬁeld
expression.

Program Structures

There are three basic structural elements needed to execute computer programs.

•

sequence

•

selection

•

iteration

A sequence, shown in Figure 4.2, is one or more statements that follow each
other.

Plex-C 1

STATEMENT

Figure 4.2

Flow chart for a sequence

A selection is a choice between several options. Figure 4.3 illustrates the follow
ing choice: If the condition A = YES is true, the CP executes statement 1, but if A
= NO is true, the CP executes statement 2.

YES

STATEMENT

Figure 4.3

Flow chart for a selection

Figure 4.4 shows a ﬂow chart for an iteration scanning the ﬁle ROUTEDATA. For
each record individual, the iteration sets the symbol variable STATE to IDLE and
the ﬁeld variable ADMSTATE equal to local number symbol ZCONNECTED.

The iteration affects all records in the ﬁle. The number of loops depends on the
number of records in ﬁle ROUTEDATA.

Program Sector

SCAN FILE
ROUTEDATA

SET STATE=IDLE

SET ADMSTATE=ZCONNECTED

SCAN FILE
ROUTEDATA

Figure 4.4

Flow chart for a FOR loop iteration

Arithmetic Operators

Plex-C uses only four different arithmetic operators.

Addition

–

Subtraction

Division

Multiplication

The processor works with non-negative integers only and truncates post-comma
digits. Division by zero is illegal and may generate a restart of the exchange.
Please avoid value overﬂows, although they do not cause a run-time error. Also
note that numerals can be speciﬁed in decimal and hexadecimal notation. Hexa
decimal numbers are preceded by a hash ‘#’ (e.g. #FF = 255).

Super-variables are ﬁeld variables with a ﬁxed size of 32 bits or more. It is not
possible to apply the arithmetic operators on super-variables, since they don’t ﬁt
into the arithmetic registers. However, the operators may be used for R variables,
the lengths of which depends on the register size of the target processor.

Logic Operators

Plex-C offers a range of six different logic operators.

Plex-C 1

(–)

NOT

invert variable bit-by-bit

SHIFT RIGHT

non-circular shift to the right by n bits

SHIFT LEFT

non-circular shift to the left by n bits

(*)

AND

(=)

EXOR

exclusive - or

(+)

These operators work at binary level. For example, the AND operator compares
bit 0 in word one and bit 0 in word two, and so forth.

The SHIFT operators ﬁll any empty positions with zeros (non-circular shift).

Example 19

This example shows the logic operator SHIFT LEFT.

Assume variable CNUM has a length of four bits and the initial value 13, which
is equal to 1101 in binary form. The following statement performs the shift left
operation.

CNUM = CNUM <= 1;

Shift Left

This statement shifts all the bits in CNUM one step to the left, and bit 0 has the
value 0. See Figure 4.5.

After

Before

Figure 4.5

Contents of the variable CNUM before and after execution of the shift left

The binary value of CNUM is equal to 1010 which corresponds to the decimal
value 10.

Program Sector

To shift left by one step is equivalent to multiplying by 2, if the ﬁgure does not
exceed the valid value range. To shift right by one bit is equivalent to dividing by
2, and faster than the division operation on most APZ processors.

Example 20

This example further demonstrates the use of different operators. Assume that
CRESULT has been declared as a 16 bit DS variable.

CRESULT = 31 + 8;

! CRESULT WILL BE 39 !

CRESULT = #1F + #8;

! CRESULT WILL BE 39 !

CRESULT = 31 * 8;

CRESULT = 31 / 8;

CRESULT = 8 / 31;

! CRESULT WILL BE 248 !

! CRESULT WILL BE 3 !

! CRESULT WILL BE 0 !

CRESULT = #FF - (8 * 31); ! CRESULT WILL BE 7!

CRESULT = (-)31;

CRESULT = 31 <= 2;

CRESULT = 31 => 2;

! CRESULT WILL BE 65504!

! CRESULT WILL BE 124 !

! CRESULT WILL BE 7 !

CRESULT = 31 (*) 8;

CRESULT = 31 (+) 8;

CRESULT = 31 (=) 8;

! CRESULT WILL BE 8 !

! CRESULT WILL BE 31 !

! CRESULT WILL BE 23 !

Consider the following example.

CRESULT = 8 – 31;

! CRESULT WILL BE 65513!

The result of this subtraction operation is a negative number. Plex-C variables and
registers cannot store negative values. Hence, a value overﬂow occurs, and the
Result Indicator Register (RIR) is set to 1 indicating the overﬂow.

The actual value of variable CRESULT is the binary complement of 8 – 31, that
is, 65513. Do not use this behaviour in a Plex program, as it is difﬁcult to under
stand and a potential source of problems in following segments of the program.

Operand

Operand is a common expression for:

•

ﬁeld variable

•

pointer

•

numeral

•

number symbol

Plex-C 1

Field Expression

A ﬁeld expression is one or several operands separated by arithmetic or logical
operators. The order of priorities in Figure 4.6 determine the order of calcula
tions, but parentheses may modify this order. In any case, the CP evaluates ﬁeld
expressions from left to right.

(–)

Highest priority

=> , <=

* , /

+ , –

(*)

(=)

(+)

Lowest priority

Figure 4.6

Order of priorities

In the ﬁeld expression 5 + 2 <= 1, the operator ‘+’ has a lower priority than ‘<=’.
The value of this ﬁeld expression would be 5 + 4 = 9.

Example 21

SUM = A + B / C * D;

Calculation of a Field Expression

After execution of the statement the variable SUM has the value of the ﬁeld
expression A + B / C * D. SUM has the value 5 if A=2, B=5, C=3 and D=3, since
the processor works calculates from left to right, see Figure 4.7.

2 + 5 / 3 x 3 = 2 + 3 = 5

Figure 4.7

Calculation of a ﬁeld expression

Program Sector

Assignment Statements

These statements assign values to ﬁeld, string and symbol variables.

The general form for an assignment statement is:

variable = expression;

The equals sign does not signify equality. It indicates that the variable is assigned
the value of the expression.

Plex-C uses three types of assignment statements:

•

ﬁeld variable assignment statements

•

symbol variable assignment statements

•

string variable assignment statements

pointer

ﬁeld variable

1..

ﬁeld variable

1..

symbol variable

SET

;

symbol variable

1..

symbol value

;

SET

string variable

1..

string

;

SET

string

ﬁeld expression

= A string variable, string symbol, or an explicit text string. Explicit

strings must begin and end with quotation marks (" ")

Figure 4.8

Syntax for variable assignment statements

The keyword SET is optional and out-of-date, do not use it any more.

Field variable assignment state

ments

assign values to ﬁeld variables and pointers.

Assigning a ﬁeld variable a symbol value results in the numeric value of the sym
bol being loaded into the ﬁeld variable.

When a variable receives a value larger than it can store, the most signiﬁcant bits
are truncated.

Plex-C 1

If a variable is structured into subvariables, the subvariable is assigned a value by
indicating the main variable followed by a period (.).

Example 22

This example assigns values to the variables TDEVNUM, CNUMBER, TNUM
BER, and ADMSTATE.

TDEVNUM = 387;

TNUMBER = CNUMBER = CNUMBER + 1;

ADMSTATE.EMCON = 0;

Figure 4.9

Field Variable Assignments

In the ﬁrst statement, the variable TDEVNUM receives the value 387. The sec
ond statement sets variable CNUMBER equal to the previous value of CNUM
BER + 1, in other words: CNUMBER is incremented by one. In addition the
temporary variable TNUMBER receives the new value. Since it is not easy to
read, avoid using this multiple assignment feature.

In the third statement, ADMSTATE is a structured variable. One of its subvaria
bles is called EMCON. This statement sets EMCON to zero.

Example 23

Consider the individual variable DEVNUM in Figure 4.10.

DEVNUM

FILE DEVDATA

DEVDATAP

Figure 4.10

The individual variable DEVNUM in ﬁle DEVDATA

Program Sector

DEVNUM is a record variable in the ﬁle DEVDATA, which has the associated
pointer DEVDATAP. The following statements assign DEVNUM in record
number 2 the value 38. DEVNUM in all the other records remains unchanged.

001

DEVDATAP = 2;

002

DEVDATAP:DEVNUM = 38;

Individual Variable Assignment

Note that the pointer has to indicate the appropriate record before execution of
the statement. The following segment of code would have the same effect.

011

DEVDATAP = 2;

012

DEVNUM = 38;

In line 12, the most recently used pointer value (here: 2) determines the number
of the record. It is recommended, though, to explicitly specify the pointer as
above in line 2.

Example 24

A similar example for an one-dimensional array.

DECLARE;

....

VARIABLE CIND 16 DS;

VARIABLE CANUM (32) 4 DS;

....

END DECLARE;

PROGRAM; PLEX;

....

CIND = 2;

CANUM (CIND) = 7;

....

END PROGRAM;

Figure 4.11

Array Assignment

CIND is a stored 16-bit variable and CANUM is a one-dimensional array con
taining 32 elements of 4 bits each.

In the program, the variable CIND receives the value 2, and the element number
two in CANUM receives the value 7.

Plex-C 1

Restrictions for using R Variables

The following rules apply when using R variables in variable assignment state
ments. Remember that the value range of an R variable is not known when writ
ing or compiling the program.

•

Do not assign a ﬁeld expression including an R variable to a variable
declared as 16 bits or less.

•

Direct numeric assignments of any variable cannot exceed 65535.

•

The value of any expression calculated at compilation cannot exceed 65535.

In other words, all code must be compatible with 16 bit and 32 bit processors. It
is not possible to write program segments that work on 32 bit processors only.
Furthermore it is not possible to include statements in the program that check at
run-time, whether the code is being executed on a 16 or a 32 bit processor.

Example 25

This examples contains two illegal statements.

DECLARE;

....

VARIABLE CANUMBER

16 DS;

VARIABLE CRNUMBER

R DS;

....

END DECLARE;

PROGRAM; PLEX;

....

CANUMBER = CRNUMBER;

! ILLEGAL STATEMENT !

CRNUMBER = 65536;

! ILLEGAL STATEMENT !

....

END PROGRAM;

Figure 4.12

Variable Assignment Statements using R Variables

Program Sector

Example 26

This example declares and sets a symbol variable.

DECLARE;

....

SYMBOL VARIABLE CSTATE = (IDLE,

BLOCKED,

BUSY) DS;

....

END DECLARE;

PROGRAM; PLEX;

....

CSTATE = BUSY;

....

END PROGRAM;

Figure 4.13

Symbol Variable Assignment

Example 27

This example assigns the value ABC1 to the string variable CALPHA.

CALPHA = "ABC1";

String Variable Assignment

Remember that string objects begin and end with quotation marks (" ").

Jump Statements

Sometimes the CP needs to jump from one place in the program to another place,
addressed by a label. The program execution can jump backwards or forwards,
see Figure 4.14. There are dozens of jumps in each software unit. Please avoid
backward jumps as far as possible, because they are difﬁcult to follow.

Plex-C 1

Program Store

Block A

L10)

L20)

IF CSTART = CNUM GO TO L10;

Forward
Jump

CNUM = CNUM + I;

TCOUNTER = CMAX;

CANUM = CBNUM;

TCOUNTER = TCOUNTER + 1;

Backward
Jump

CTEST = TCOUNTER;

IF TCOUNTER = CSTART GOTO L20;

Figure 4.14

Forward and backward jumps

The target of the jump or label has to be unique in the program sector.

In Plex-C, there are two types of jump statements:

•

Unconditional jump statements

•

Conditional jump statements

Unconditional jump statements always lead to a jump to the indicated label. In a
conditional jump statement, a jump only occurs when a certain condition is met.

Try to avoid jump statements, since they can give rise to a poor program struc
ture. It is very difﬁcult to read a program with a great many jump statements.

Unconditional Jump Statement

GO TO

label ;

GOTO

label = Program label to which a jump is made. Must be unique in a program
sector or statement block.

Figure 4.15

Syntax for Unconditional Jump

Program Sector

The unconditional jump statement results in a jump to the label indicated.

Example 28

This example shows a GOTO jump to the label START10.

PROGRAM; PLEX;

....

GOTO START10;

....

START10)

TCOUNTER = CMAX;

An Unconditional Jump

Conditional Jump Statement

This statement jumps to a given program position if a certain condition is met.

PROCEED ELSE

NOT

condition = A comparison between:

and end with quotation marks.

label = Program label to which a jump is made. Must be unique within a pro
gram sector or statement block.

GOTO

label

;

condition

- two ﬁeld expressions
- a symbol variable and a symbol value
- two string objects. A string object is a string variable, string

symbol or an explicit text string. Explicit strings must begin

GO TO

Figure 4.16

Syntax for Conditional Jump Statement

Use the following operators in a comparison:

equal to

not equal to

is less than

The operators <, >, =<, >=

is greater than

may only be used for

is less than or equal to

comparing numeric ﬁeld
expressions!

is greater than or equal to

When comparing two string objects, or a symbol variable with a symbol value,
only the ‘=’ and the ‘/=’ operators are available.

Plex-C 1

Example 29

This example shows a conditional jump.

PROGRAM; PLEX;

....

IF TCOUNTER >= CMAX GOTO ALARGE10;

TCOUNTER = TCOUNTER + 1;

....

ALARGE10)

TCOUNTER = 0;

Conditional Jump 1

If the value of the variable TCOUNTER is greater than or equal to the value of
CMAX, the execution continues at label ALARGE10. If not, the CP executes the
next statement, TCOUNTER = TCOUNTER + 1; .

The IF ... PROCEED ELSE statement has the same effects:

PROGRAM; PLEX;

....

IF TCOUNTER < CMAX PROCEED

ELSE GOTO ALARGE10;

TCOUNTER = TCOUNTER + 1;

....

ALARGE10)

TCOUNTER = 0;

Conditional Jump 2

Example 30

This example shows the use of a negation in the conditional jump statement.

PROGRAM; PLEX;

....

IF NOT STATE = IDLE GOTO L20;

....

L20)

TCOUNTER = 0;

Conditional Jump with Negation

If STATE has the value IDLE, program execution continues with the next state
ment. If STATE has any other value, the program execution continues at label
L20.

Program Sector

Do not use NOT and PROCEED ELSE in the same IF statement, since it can be
replaced by an IF statement without the two constructs (double negation).

Conditional Statements

Avoid the IF ... GOTO statement, since the only action permitted is a GOTO
jump. The IF ... THEN ... ELSE statement is much more ﬂexible and allows to
select among an arbitrary number of conditions.

1..

NOT

condition

THEN

sequence of statements

ELSIF

ELSE

sequence of statements

FI ;

condition = A comparison between:

- two ﬁeld expressions
- a symbol variable and a symbol value
- two string objects. A string object is a string variable, string

symbol or an explicit text string. Explicit strings must begin
and end with quotation marks.

Figure 4.17

Syntax for IF ... THEN

Single signal reception statements (see Chapter 6, Block Interaction) and entry
labels accessible from outside the local sequence of statements part may not be
used in the sequence of statements part. In other words, it is illegal to jump into
an IF statement.

Note that it is not possible to combine several conditions using operators like
AND and OR. Such operators do not exist in Plex.

Example 31

This example shows a single comparison of the variable CNUM:

PROGRAM; PLEX;

....

IF CNUM = 5 THEN

CNUM = CNUM + 1;

FI;

One Condition

If the value of CNUM is equal to 5, CNUM is incremented by one.

Plex-C 1

Example 32

This example examines four different conditions for the variable CMONTH.

PROGRAM; PLEX;

....

IF CMONTH < 4 THEN

CSEASON = WINTER;

ELSIF CMONTH < 7 THEN

CSEASON = SPRING;

ELSIF CMONTH < 10 THEN

CSEASON = SUMMER;

ELSE

CSEASON = AUTUMN;

CSEASONUS = FALL;

FI;

Figure 4.18

Four Conditions

If the variable CMONTH has a value between 0 and 3, the program sets CSEA
SON to WINTER. If the variable CMONTH has a value between 4 and 6, the
program sets CSEASON to SPRING. If the variable CMONTH has a value
between 7 and 9, the program sets CSEASON to SUMMER. In all other cases
two statements, the program sets CSEASON to AUTUMN and CSEASONUS to
FALL.

The CASE statement below can implement the same behaviour.

Selection Statement

The CASE statement picks one selection out of several choices. Please consider
the syntax box on page 67.

Do not use single signal reception statements (see Chapter 6, Block Interaction)
in the sequence of statements part and do not jump into a CASE statement. Note
that the OTHERWISE DO part is mandatory.

In a CASE statement, each choice must be unambiguous.

Program Sector

CASE

OTHERWISE DO

sequence of statements

ESAC ;

value

sequence of statements

1..

WHEN

1..

value =

symbol variable

string variable

string symbol

number symbol

symbol value

string symbol

expression

expression =

ﬁeld expression

explicit text string

numeral

explicit text string

Figure 4.19

Syntax for CASE

Example 33

PROGRAM; PLEX;

....

CASE CMONTH IS

WHEN 0, 1, 2, 3 DO

CSEASON = WINTER;

WHEN 4, 5, 6 DO

CSEASON = SPRING;

WHEN 7, 8, 9 DO

CSEASON = SUMMER;

OTHERWISE DO

CSEASON = AUTUMN;

CSEASONUS = FALL;

ESAC;

Figure 4.20

Selection based on a Field Variable

If CMONTH is equal to 0, 1, 2, or 3, the variable CSEASON is set to WINTER.

If CMONTH is equal to 4, 5, or 6, the variable CSEASON is set to SPRING.

If CMONTH is equal to 7, 8, or 9, the variable CSEASON is set to SUMMER.

Otherwise the program sets CSEASON to AUTUMN and CSEASONUS to
FALL.

Plex-C 1

Example 34

This example shows the use of CASE for a string variable.

PROGRAM; PLEX;

....

CASE CTEXT IS

WHEN "START","STOP","INT" DO

STATE = BLOCKED;

TCOUNTER = TCOUNTER + 1;

WHEN "RUNNING" DO

TCOUNTER = STARTVALUE;

OTHERWISE DO;

ESAC;

Figure 4.21

Selection based on a String Variable

If the string variable CTEXT contains either "START", "STOP", or "INT", the
symbol variable STATE receives the value BLOCKED and the variable
TCOUNTER is incremented by one.

If CTEXT contains the value "RUNNING", TCOUNTER receives the value of
STARTVALUE.

In all other cases there is no action, and the program executes the statement after
ESAC.

Iteration Statements

Plex-C offers three different loops or iteration statements. All of them behave like
FOR loops in other programming languages. Plex-C programs use iterations for
scanning ﬁles or indexed variables between given start and stop values.

There are three types of iteration statements:

•

FOR ALL

•

FOR FIRST

Scanning is normally quite a slow process. However, under certain conditions,
the FOR statements can result in high-speed ASA instructions FESR and FIRSI;
see page 77. If the compiler can generate FESR or FIRSI, please use one of the
FOR loops. If not, most designers prefer ON instead of FOR ALL, because the
ON loop is easier to read.

The ON Statement

Only ON loops may scan from either the highest to the lowest value of the itera
tion variable, or from the lowest to the highest.

Program Sector

pointer

UPTO

FROM

ﬁeld expression 1

ﬁeld variable

DOWNTO

ﬁeld expression 2

sequence of statements

NO ;

pointer/ﬁeld variable = Iteration variable.

ﬁeld expression 1 = The iteration starts from the value of ﬁeld expression 1.

ﬁeld expression 2 = The iteration ends at the value of ﬁeld expression 2.

Figure 4.22

Syntax for ON

The iteration variable is either a pointer or a ﬁeld variable. Use pointers when
scanning ﬁles. Use ﬁeld variables when scanning indexed variables, preferring
temporary iteration variables which make the loop faster.

After execution of an ON statement, the value of its iteration variable is unde
ﬁned! If the iteration variable is a temporary one, do not send or receive com
bined signals (see Chapter 6, Block Interaction) in the sequence of statements.

Use UPTO when scanning from the lowest to the highest value and, similarly,
DOWNTO when scanning from the highest to the lowest value.

With UPTO, make sure the value of ﬁeld expression 1 is smaller than the value of
ﬁeld expression 2. Consequently, with DOWNTO, make sure the value of ﬁeld
expression 1 is greater than the value of ﬁeld expression 2. If not, the sequence of
statements is not executed.

Example 35

This example scans the ﬁle DEVDATA, shown in Figure 4.23. The pointer DEV
DATAPOINTER contains the current record number in this ﬁle.

Variable CINDNUM contains the number of record individuals in the ﬁle. In this
example, the number of records is 16.

Plex-C 1

CINDNUM

FILE

STATE

DEVDATAPOINTER

DEVDATA

Figure 4.23

The ﬁle DEVDATA

PROGRAM; PLEX;

....

ON DEVDATAPOINTER FROM CINDNUM-1 DOWNTO 0 DO

STATE = IDLE;

NO;

Scanning a File with ON

After execution of the ON statement, the symbol variable STATE has the value
IDLE in every record in the ﬁle.

After scanning all the records from the start value (CINDNUM-1) to the stop
value (0), the CP executes the statement after the ON statement. Remember that
DEVDATAPOINTER is not zero after the loop: instead its value is unknown.

Please note that if CINDNUM is the number of records in the ﬁle, the record with
the highest number is CINDNUM–1, since numbering starts at record number 0.

Example 36

This example assigns the values 5 and 6 to the indexed variables A and B for all
index values between MIN and MAX.

Program Sector

PROGRAM; PLEX;

....

ON TI FROM MIN UPTO MAX DO

A(TI) = 5;

B(TI) = 6;

NO;

Scanning an Array with ON

If, for example, MIN has the value 10 and MAX the value 14, elements 10 to 14
in the two arrays receive the values 5 and 6, respectively; see Figure 4.24.

A(10) A(11) A(12) A(13) A(14)

B(10) B(11) B(12) B(13) B(14)

Figure 4.24

Values of arrays A and B after execution of the ON loop

The FOR ALL statement

The FOR ALL statement scans from the highest to the lowest index value, see
page 72. If ﬁeld expression 2 is greater than ﬁeld expression 1, no search is made,
and the program executes the statement after the FOR ALL statement. Field
expression 2 can be omitted if it is 0.

As with ON, the iteration variable is undeﬁned after a FOR ALL loop.

Plex-C 1

pointer/ﬁeld variable 1

condition = A comparison between:

statement
EXIT or a signal reception statement (see Chapter 6,

and

Chapter 8, Input and Output Statements)

= Name of a statement block, assembly sector or a pro

cedure (see Chapter 7, Call Routines).

statement

pointer

ﬁeld variable 1

FOR ALL

FROM

UNTIL

condition

ﬁeld variable 2

IS CHANGED TO

WHERE

NOT

;

= Iteration variable. The iteration variable is either a

pointer or a ﬁeld variable. Pointers are used to scan ﬁles. Field variables are
used to scan indexed variables.

ﬁeld expression 1 = The iteration starts from the value of ﬁeld expression 1.

ﬁeld expression 2 = The iteration ends at the value of ﬁeld expression 2.

- two ﬁeld expressions
- a symbol variable and a symbol value
- two string objects. A string object is a string variable, a string
symbol or an explicit text string.

ﬁeld variable 2/ﬁeld expression 3 = A check that the value of ﬁeld variable 2
is equal to the value of ﬁeld expression 3.

= One statement, which can be any statement except COMMAND,

Block Interaction

. GOTO may not be used either.

statement block name

ﬁeld expression 1

ﬁeld expression 2

ﬁeld expression 3

Figure 4.25

Syntax for the FOR ALL loop

Example 37

This example scans the ﬁle REC, shown in Figure 4.26, using FOR ALL.

The value of the variable CINDNUM (here: 16) is the number of records in the
ﬁle REC.

Program Sector

NUMB

FILE REC

RECPOINTER

CMIN

CINDNUM

CINDNUM-1

STATE

Figure 4.26

The ﬁle REC with the pointer RECPOINTER

PROGRAM; PLEX;

....

FOR ALL RECPOINTER FROM CINDNUM-1

DO NUMB = 256;

Scanning all records with FOR ALL

FOR ALL indicates that the iteration covers all speciﬁed records in the ﬁle. The
iteration starts from the record with the highest pointer value (CINDNUM-1),
and continues to the record number zero.

The variable NUMB receives the value 256 in each record. When the whole ﬁle
has been scanned, the program executes the statement after the FOR statement.
Similar to the ON loop, the iteration variable RECPOINTER is undeﬁned after
the loop.

PROGRAM; PLEX;

....

FOR ALL RECPOINTER FROM CINDNUM-1 UNTIL CMIN

DO NUMB = 256;

Scanning of a part of the ﬁle with FOR

Plex-C 1

This example has the same behaviour as the last one, with the only exception
being that iteration starts at CINDNUM-1 and stops at 5, which is the value of the
variable CMIN. Hence, the variable NUMB is 256 in records number 5 to 15.

Search Condition

The action part of any FOR loop can be executed conditionally by indicating a
search condition (WHERE...). The syntax for the search condition is the same as
for conditional expressions in IF statements.

Countdown with IS CHANGED TO

Time supervision and other programs use the IS CHANGED TO construct. With
this statement, the program compares the variable before IS with the variable
after TO. If the values are equal, nothing happens. If they are not, the value of the
ﬁrst variable is decremented by one, and a new comparison is performed. If the
values are equal at this second comparison, the program executes the action part.

Example 38

This example uses the ﬁle REC from Example 37 again.

PROGRAM; PLEX;

....

FOR ALL RECPOINTER FROM CINDNUM-1

WHERE NUMB IS CHANGED TO CTIME

DO STATE = BUSY;

Figure 4.27

Scanning of a File, using FOR ... IS CHANGED

The iteration statement in this example consists of a change condition (...IS
CHANGED TO...). The change condition monitors the value of the variable
NUMB and compares it with variable CTIME.

If NUMB and CTIME have equal values, nothing happens. But if the value of
NUMB is not equal to CTIME, the value of NUMB is decremented by one. If the
subtraction results in an agreement (NUMB=CTIME), the program executes the
statement after DO, here STATE = BUSY.

As in previous examples, the iteration starts with the record having the highest
number (CINDNUM-1). FOR ALL... indicates that the iteration affects all
records in the ﬁle meeting the condition.

This construction is frequently used for tasks requiring periodic execution. Each
record in the ﬁle contains data for a certain task. A counter, in this example varia
ble NUMB, determines the waiting time until the next execution of the task.
When NUMB has reached the value CTIME, the task is executed.

The WHERE ... IS CHANGED TO construct may scan all records in the ﬁle at
periodic intervals, and then decrements all counters (NUMB) by one. If the coun

Program Sector

ter has reached the critical value CTIME + 1, the iteration decrements the counter
for the last time, and takes further action.

This may include resetting the counter (NUMB) to a new start value greater than
CTIME to repeat the task at a later time.

The FOR ALL loop executes the action part for all records (or elements in an
array) fulﬁlling the condition. The FOR FIRST loop provides a different type of
iterative statement. The FOR FIRST loop executes the action part only for the
ﬁrst encountered record (or element) that fulﬁls the search condition, and then
the loop terminates.

The FOR FIRST statement

The FOR FIRST loop scans from the highest to the lowest value. Note that the
WHERE part is mandatory in the FOR FIRST loop.

statement

pointer

ﬁeld variable 1

FOR FIRST

FROM

UNTIL

condition

ﬁeld variable 2

IS CHANGED TO

WHERE

NOT

;

GOTO

label

statement block name

ﬁeld expression 1

ﬁeld expression 2

ﬁeld expression 3

GO TO

Figure 4.28

Syntax for the FOR FIRST loop

Please see page 76 for syntax explanations.

The iteration variable is deﬁned after a FOR FIRST loop, provided that the search
was successful (WHERE condition was satisﬁed) and the program executed the
action part (GOTO or DO).

Plex-C 1

pointer/ﬁeld variable 1 = Iteration variable. The iteration variable is either a
pointer or a ﬁeld variable.

ﬁeld expression 1 = The iteration starts from the value of ﬁeld expression 1.

ﬁeld expression 2 = The iteration ends at the value of ﬁeld expression 2.

condition = A comparison between:

- two ﬁeld expressions
- a symbol variable and a symbol value
- two string objects. A string object is a string variable, a string
symbol or an explicit text string.

ﬁeld variable 2/ﬁeld expression 3 = A check that the value of ﬁeld variable 2
is equal to the value of ﬁeld expression 3.

statement = One statement, which can be any statement except COMMAND,
EXIT or a signal reception statement (see Chapter 6, Block Interaction and
Chapter 8, Input and Output Statements).

statement block name = Name of a statement block, assembly sector or a pro
cedure (see Chapter 7, Call Routines).

Example 39

This example scans the same ﬁle as in Example 37.

PROGRAM; PLEX;

....

FOR FIRST RECPOINTER FROM CINDNUM-1

WHERE STATE = IDLE

DO STATE = BUSY;

Figure 4.29

Scanning of a File, using FOR FIRST and a Condition

The FOR FIRST loop ﬁnds the ﬁrst idle record in the ﬁle. The iteration starts with
the record having the highest pointer value (CINDNUM-1).

For the ﬁrst record found where the value of the variable STATE is IDLE, the
loop sets the value of the variable STATE to BUSY and terminates. The program
continues with the statement after the FOR FIRST statement. This means that the
iteration only continues until ﬁnding one record meeting the condition.

After scanning the whole ﬁle without ﬁnding any record in which the STATE
equals IDLE, the statement after the FOR statement is executed.

Program Sector

High-Speed Iterations

As mentioned before, the advantage of the FOR ALL/FIRST statements is that
they may result in the high-speed ASA instructions FESR and FIRSI.

FESR is the fast ASA statement for loops over ﬁles of records, FIRSI is the fast
ASA statement for loops over arrays. The following pages discusses the circum
stances and conditions on the FOR ALL/FIRST statements to compile into FESR
or FIRSI.

FESR Loops

Figure 4.30 shows the general syntax for the FOR statement that may generate
FESR.

FIRST

FOR

pointer

FROM

ﬁeld expression 1

ALL

UNTIL

ﬁeld expression

statement

WHERE

variable = expression

;

statement block name

Figure 4.30

Syntax for generating the ASA instruction FESR

Conditions for Generating FESR

Variable is an individual variable, belonging to a record indicated by
pointer.

Variable is a simple DS variable, that is, neither structured, indexed or a
string. The variable is stored in pointer register 1 (PR1).

The operator in the condition must be the equals sign (variable=expres-
sion).

Expression must be constant, that is, not change value during the loop.
Expression may not, for example, contain pointer because pointer is the
iteration variable which changes value during the loop. The value of
expression is stored in the compare register CR.

Statement must be one of the statements BRANCH, GOTO, SEND, EXIT,
TRANSFER, RETURN. Statement can also be an assignment statement. If
statement is an assignment statement, it must not change the value of
expression or pointer. For example, the assignment statement "pointer =
X" is not allowed, since it changes the value of pointer.

If a statement block is used, it must be linked. A statement block is linked
if the compiler generates ASA code that results in a jump to this statement

Plex-C 1

block. The alternative is that the statement block is placed directly after the
call in the assembler code.

Whether or not a statement block is linked depends on:

•

the number of statements in the statement block

•

the number of places in the program calling the statement block.

Chapter 7, Call Routines, discusses statement blocks in detail.

Example 40

This example shows a FOR statement compiling into an FESR instruction.

DECLARE;

....

NSYMB ZMAX=200;

....

RECORD REC;

VARIABLE NUMB 16 DS;

END RECORD;

POINTER RECPOINTER (REC);

....

VARIABLE A,

E 16 DS;

....

END DECLARE;

PROGRAM; PLEX;

....

FOR ALL RECPOINTER FROM ZMAX-1

WHERE NUMB = A + B

DO D = E;

....

Figure 4.31

An FESR-generating FOR ALL loop

Example 41

This example shows a FOR statement not compiling into an FESR instruction.

Program Sector

PROGRAM; PLEX;

....

FOR ALL RECPOINTER FROM ZMAX-1

WHERE NUMB = A + B

DO A = E;

Figure 4.32

A non-FESR-generating FOR ALL loop

This loop does not result in an FESR instruction. The reason for this is that the
statement A = E causes a change in the value of the expression A + B during the
loop.

FIRSI Loops

These loops initialise an array with a constant value using a single ASA instruc
tion, FIRSI.

FOR ALL

index FROM field expression 1

UNTIL field expression 2

array ( index ) = expression

;

array ( constantindex, index ) = expression

Figure 4.33

Syntax for generating the ASA instruction FIRSI

To generate FIRSI, both expression and constantindex cannot change during the
loop. Thus, in two-dimensional arrays, only the second index may contain the
iteration variable.

It is not possible to use the FOR FIRST loop or the WHERE construct when gen
erating FIRSI.

Loop Comparison

Figure 4.34 shows the pros and cons of the three iteration statements.

Plex-C 1

Criterion

FOR ALL FOR FIRST

Ascending or descending order

Yes

Always descending

No, except in statement

Several statements in action part

Yes

blocks, IF, CASE and loop
statements

Condition in iteration statement

Possible

Always

Iteration ends after matching con
dition once and handling one indi
vidual

Not
applicable

Yes

deﬁned if

Iteration variable/pointer after loop

undeﬁned

matching
individual/
condition

Generates high-speed loop

Possible

Figure 4.34

Plex-C iteration statements - a comparison

Old Statements

Do not use the statements described in this section in new design. However, it is
useful to know the function of these old statements, because block designers
often have to make corrections in existing programs that contain these statements.

BRANCH Statement

The BRANCH statement selects between an arbitrary number of program
sequences. With this statement, the program jumps on the basis of either ﬁeld
expressions or symbol variables. If the condition includes a ﬁeld expression, the
following syntax applies.

1..

ELSE TO

label

;

label

label = Program label to which a jump is made if the condition is met.

cated. If the condition is not met, a jump is made to the program label after

1..

BRANCH ON

numeral

numeral = Indicated in decimal, hexadecimal or symbol form. If the ﬁeld
expression is equal to the numeral, a jump is made to the program label indi

ELSE TO.

ﬁeld expression

Figure 4.35

Syntax for BRANCH ON a Field Variable

Program Sector

Example 42

This example shows branching on a ﬁeld variable.

PROGRAM; PLEX;

....

BRANCH ON A

TO LAB1 IF 5

TO LAB2 IF 6,7

ELSE TO LAB3;

Figure 4.36

BRANCH ON a Field Variable

If A equals 5, the program jumps to label LAB1. If the value of A is 6 or 7, the
program jumps to label LAB2. If A has none of the values 5, 6, or 7, the jump
goes to LAB3.

For jumping on symbol variables the following syntax applies.

symbol value

1..

ELSE TO

label ;

label

1..

BRANCH ON

symbol variable

Figure 4.37

Syntax for BRANCH ON a Symbol Variable

Example 43

This example shows branching on a symbol variable.

PROGRAM; PLEX;

....

BRANCH ON STATE

TO L1 IF BUSY, BLOCKED

TO L2 IF IDLE

ELSE TO L3;

Figure 4.38

BRANCH ON a Symbol Variable

If the value of STATE is BUSY or BLOCKED, the program jumps to label L1. If
STATE = IDLE, the program jumps to L2. If the value of STATE is other than
IDLE, BLOCKED or BUSY, the jump goes to L3.

Plex-C 1

In all new designs, designers need to use the CASE statement instead of the
BRANCH statement.

ON CARRY

When the central processor calculates the value of an expression, overﬂow can
occur. Some old programs contain an overﬂow check, namely the CARRY con
struct having the following syntax.

NOT

label

CARRY

>, ON

GOTO

label

;

= Program label to which a jump is made if overﬂow occurs.

ﬁeld variable assignment

GO TO

Figure 4.39

Syntax for ON CARRY

Example 44

In this example, the program checks whether overﬂow occurs when subtracting C
from B.

PROGRAM; PLEX;

...

A = B - C, ON CARRY GOTO ERROR;

Figure 4.40

Overﬂow Check with ON CARRY

If C is larger than B, the result of the subtraction is negative (overﬂow). If over
ﬂow occurs, the program jumps to the label ERROR. If no overﬂow occurs, the
execution continues with the next statement.

Today, designers use the following statements instead.

Program Sector

PROGRAM; PLEX;

....

IF B >= C THEN

A = B - C;

ELSE

! ERROR HANDLING !

FI;

Figure 4.41

Overﬂow Check for New Designs

The ﬁrst statement checks whether C is greater than B. If C is greater than B, the
program jumps to the label ERROR, otherwise the execution continues.

Chapter Summary

This chapter introduced some general programming concepts and discussed the
following Plex-C statements:

•

SET

•

GOTO

•

IF . . . GOTO

•

IF . . . THEN . . . ELSIF . . . ELSE

•

CASE

•

FOR ALL

•

FOR FIRST

•

BRANCH ON

•

ON CARRY

References

[1]

AXE ASA 210 C Guide,
EN/LZT 1011 837,
© Ericsson Telecom AB 1998

[2]

Plex-C Compiler Support for APZ 212 30 (function speciﬁcation)
49/155 17-APS 301 01
© Ericsson Telecom 1997

Plex-C 1

Chapter 5

Data Sector

Introduction

A Plex document consists of a declare sector, at least one program sector, and a
data sector. The declare sector deﬁnes constants and declares variables. Initial
values are assigned to some variables in the data sector. The data sector also con
tains statements to set the number of records in a ﬁle.

These initial values only apply the ﬁrst time the exchange is started (unless the
ﬁle size is ﬁxed). In addition, the data sector includes allocation statements, spec
ifying the order of the variables in the data store. This chapter describes the vari
ous statements in the data sector, as well as the principles of addressing data.

Chapter Objectives

After completing this chapter and the exercises you are able to:

• write the data sector statements for:

−

ﬁle-size deﬁnition

−

variable assignment

−

variable allocation

• describe the principles of addressing data

Figure 5.1

Chapter Objectives

File-Size Deﬁnition Statement

The ﬁle size is the number of records in a ﬁle. The ﬁle-size deﬁnition statement in
the data sector has the following syntax:

SIZE OF record name = value ;

record name = The name of the ﬁle.

value = A number or symbol. May not be greater than 65535, even for ﬁles
with R pointers.

Figure 5.2

Syntax for File–Size Deﬁnition

Plex-C 1

The number of records in a ﬁle is either alterable or ﬁxed. A parameter in the
parameter list speciﬁes if the SW unit permits alteration of the ﬁles size (in other
words, “the block participates in a ﬁle-size alteration event”). In this case, the
operator or tester can alter the ﬁle size by command and the data sector usually
sets the initial ﬁle-size to 0 (zero).

If the record variables use less than 50 KW16 (kilowords of 16 bits) memory in
the data store, it is preferable to use a ﬁle with a ﬁxed ﬁle size according to a
design rule.

Example 45

Assume the ﬁle shown in Figure 5.3.

FILE

NUMBER

STATE

DEVDATAPOINTER

DEVDATA

STATE

Figure 5.3

File DEVDATA with n + 1 records

The following statement in the data sector sets the ﬁle size.

DATA;

....

SIZE OF DEVDATA = 500;

Figure 5.4

File Size - Deﬁned as a Number

After compiling the program, the ﬁle DEVDATA consists of 500 records.

If the ﬁle size is ﬁxed, the value is usually declared as a local number symbol (see
Example 46 on page 87).

Data Sector

Example 46

In this example, the ﬁle DEVDATA and the local number symbol ZINDNUMD
have been declared in the declare sector. ZINDNUMD contains the number of
record individuals in the ﬁle DEVDATA. The declare sector sets the local number
symbol to 42.

DECLARE;

....

NSYMB ZINDNUMD = 42;

....

RECORD DEVDATA;

....

END RECORD;

POINTER DEVDATAPTR (DEVDATA);

....

END DECLARE;

PROGRAM; PLEX;

....

END PROGRAM;

DATA;

....

SIZE OF DEVDATA = ZINDNUMD;

....

END DATA;

Figure 5.5

File Size - Deﬁned as a Local Symbol

The statement in the data sector (SIZE OF DEVDATA = ZINDNUMD) reserves
space for 42 records in the data store. The value range of pointer DEVDATAPTR
is, consequently, 0 to 41.

Variable Assignment Statements

These statements set initial values for stored variables supporting the following
types of variables:

•

common variables

•

individual variables (variables inside a record)

It is optional to set initial values to stored variables. If a variable did not receive
an initial value, its start value is undeﬁned unless the variable has the property
CLEAR.

Notes

indexed variables with the maximum number of elements cannot get their
initial values from the data sector

Plex-C 1

R variables may not receive values greater than 65535 in the data sector

Common Variable Assignment Statements

Common variable assignment statements give initial values to common variables.

ﬁeld variable =

ﬁeld expression

"text string"

[ SET ]

string variable =

;

string symbol

symbol variable = symbol value

Figure 5.6

Syntax for Common Variable Assignment

Example 47 shows how to use common variable assignment statements.

Example 47

This program segment assigns initial values to the stored variables CMAX and
CNUM and to the second element of the array CARRAY.

DATA;

....

CMAX = 100;

CNUM = ASYMB;

CARRAY (1) = 7;

....

END DATA;

Figure 5.7

Assigning Start Values

Executing the program the very ﬁrst time, usually at the start of the exchange, the
variables receive the following values:

•

The initial value of the variable CMAX will be 100.

•

The initial value of the variable CNUM will be equal to the value of
ASYMB. (In this example, ASYMB is a global number symbol, which has
received its value in the parameter list.)

•

The initial value of element number one in the array CARRAY will be 7.

Data Sector

Individual Variable Assignment Statements

These statements give initial values to individual variables.

[ SET ]

;

1..

FOR

pointer =

"text string"

string symbol

string variable =

symbol variable = symbol value

ﬁeld variable =

ﬁeld expression

ﬁeld expression 2

ﬁeld expression 1

Figure 5.8

Syntax for Individual Variable Assignment

Notes

the value of ﬁeld expression 1 must be less than that of ﬁeld expression 2.

when omitting ﬁeld expression 2, the variable assignment is performed up
to the last record in the ﬁle. This statement would assign initial values to
the variables in all or some of the records in the ﬁle. If the statement lists
only certain pointer values (record numbers), the variables of the other
records are set to zero.

even for ﬁles having R pointers the parameters ﬁeld expression 1 and ﬁeld
expression 2 may not be larger than 65535.

Example 48

Consider the ﬁle DEVDATA in Figure 5.3. The following assignment statement
assigns the value 58 to the variable NUMBER in records 100 to 200 and in
records 300 to 400.

DATA;

....

NUMBER=58 FOR DEVDATAPOINTER = 100 TO 200,

300 TO 400;

....

END DATA;

Figure 5.9

Assigning the value 58 to the variable NUMBER

In all other records, the variable NUMBER receives the value 0.

Plex-C 1

Example 49

To assign the value IDLE to all STATE variables in the ﬁle DEVDATA, insert the
following statement.

DATA;

....

STATE = IDLE FOR DEVDATAPOINTER = 0;

....

END DATA;

Figure 5.10

Assigning the value IDLE to all STATE variables

In this case, omit TO ... to assign the value IDLE to all records in the ﬁle. It is not
necessary to know the current number of records in the ﬁle.

Allocating Variables in the Data Store

To specify the order in which variables are allocated in the data store, use an allo
cation statement. To understand the function of this statement in the data sector,
you will ﬁrst need to know how a block addresses its data.

Addressing Data

The DS stores the variable values for all software units. Each DS variable belongs
to one CP software unit, and can only be accessed from that speciﬁc software
unit. To ﬁnd these variables in the DS, the program uses the reference store. See
Figure 5.11.

In the reference store (RS), each CP software unit has its own area in the refer
ence table (RT) and in the base address table (BAT). One item indicated in the
reference table is the base start address (BSA). The BSA indicates where, in the
reference store, the BAT for a speciﬁc function block starts.

In the BAT, each variable has its own position. The BAT contains information
about all stored variables in a function block, such as variable type, variable
length and word address (WA). The WA states the absolute address for the varia
ble in the DS.

Data Sector

Block A

Block X

Block A

Block X

Reference Store

BSA

BAT

RT = Reference Table

BAT = Base Address Table

BSA = Base Start Address

WA = Word Address

Data Store

Figure 5.11

Reference store and data store

To ﬁnd the position in the BAT of a speciﬁc variable, the program uses the base
address number (BAN). The program should give a BAN to each stored variable
in an allocation statement in the data sector. This BAN states the relative address
for this variable in the BAT. The BAN is relative to the base start address. Figure
5.12 illustrates how the program ﬁnds a variable in the DS.

Plex-C 1

Reference Store

Data Store

Block A

Block X

Block A

Block X

RT = Reference Table

BAT = Base Address Table

BSA = Base Start Address

WA = Word Address

BSA

BAT

Figure 5.12

Addressing a variable in the data store

Notes to Figure 5.12

The BSA indicates the starting point of the base address table for function
block X, located in the reference store. The BSA gives the absolute
address.

The BAN indicates where in the BAT the word address for a speciﬁc varia
ble is found. The BAN is a relative address.

The WA indicates where the value of a speciﬁc variable is stored in the DS.
The WA is an absolute address.

Data Sector

Storing Individual Variables

The data store does not keep records in consecutive order. Instead, the data store
keeps all instances of an individual variable together, with its values from all
records (Figure 5.13). For instance, the DS groups all occurrences of the individ
ual variable STATE in consecutive order.

CHARG

ANUM

Data Store

ANUM

CHARG

0
1

1
2

STATE

Figure 5.13

Individual variables stored in the data store

Individual variables follow the usual addressing principles. In addition, a pointer
value indicates the number of the current record. Figure 5.14 illustrates how to
access the individual variable CHARG in record number 3.

Note that records and ﬁles are not visible anywhere in the data store. Neither
records nor ﬁles of records are stored consecutively in the DS.

Plex-C 1

Data Store

0
1
2
3

pointer value: 3

STATE

ANUM

CHARG

WA = Word Address

Figure 5.14

Addressing an individual variable

In this ﬁgure, the WA indicates the starting point of the variable CHARG. The
pointer value (which is 3 here) is then added to the WA to ﬁnd the individual var
iable for a speciﬁc record.

Allocation Statement

These statements specify how DS and buffer variables are to be stored. The varia
bles receive their base address number (see Addressing Data on page 90). The
numbering of BANs starts with 1, not 0.

ALLOCATE variable AT BASE ADDRESS ban

;

variable = The name of the stored variable to be allocated.

ban = The base address number; a number that indicates the relative address in
the base address table.

Figure 5.15

Syntax for Variable Allocation (New Design)

Data Sector

Notes

The syntax for the variable allocation used in old designs is shown on page
96.

For variables not allocated in the data sector, the compiler automatically
allocates space in the DS during compilation. Nevertheless, you should
allocate all stored variables.

There is no difference between allocating a common and an individual var
iable. Regardless of the number of actual or future records, there is only
one allocation statement for each individual variable.

The following example shows how to allocate a variable in the data sector.

Example 50

This statement allocates the individual stored variable NUMBER in the DS.

DATA;

....

ALLOCATE NUMBER AT BASE ADDRESS 25;

After compilation, the compiler inserts the WA for the variable NUMBER at the
relative address 25 in the base address table. See Figure 5.16.

Reference Store

Base Address Table

WA = Word Address

Figure 5.16

Allocating a variable to base address 25

Plex-C 1

The following frame shows the complete syntax of the variable allocation state
ment. The elements shown here should not be used any more in new design.

BASE ADDRESS ban

ABSOLUTE ADDRESS

;

variable

ban

data store.

ALLOCATE

le AT

ABSOLUTE ADDRESS

BASE ADDRESS ban

numeral

= The name of the stored variable to be allocated.

= The base address number; a number that indicates the relative address in

the Base Address Table.

numeral = A number that indicates the absolute address (word address) in the

var ab

numera

Figure 5.17

Syntax for Variable Allocation (Old Design)

Notes

The syntax for the variable allocation used in new design is shown on page
94.

Never set the ABSOLUTE ADDRESS in the allocate statement. It is auto
matically assigned by the operating system.

Sometimes the terms variable number or alpha-parameter are used instead
of base address number.

Reasons for Variable Allocation

The main reason for allocating stored variables an address is the treatment of the
base address table in a function change. In a function change, when old software
is replaced with new software, the order of the variables in the two base address
tables might be completely different. Consequently, the transfer of variable val
ues and rearrangement of the reference store would take a lot of time. If, instead,
all the variables have been allocated in the same order in the old and the new
block, the transfer will be much faster.

Another reason to allocate variables is that variables which are allocated a base
address number between 1 and 63 will be accessed faster than variables with
BANs of 64 or higher. The special ASA instructions RSA (read store abridged)
and WSA (write store abridged) provide particularly quick access to those varia
bles that have a BAN of less than 64. Hence, the designer can choose which of the
stored variables in a function block should be accessed fast during program exe
cution by allocating low BANs to these variables.

Data Sector

Chapter Summary

From this chapter, you should remember these points:

•

The data sector is used to assign initial values to variables and alterable ﬁle
sizes (for use only at the very ﬁrst start-up of the exchange). You may also
assign a ﬁxed size to a ﬁle of records.

•

There are three types of data sector statements:

−

File-size deﬁnition statements deﬁne the number of records in a ﬁle.

−

Variable assignment statements assign initial values to variables.

−

Variable allocation statements allocate addresses in the BAT for
stored variables.

•

To locate the value of a speciﬁc variable, read the:

−

BN, which gives you the BSA to the BAT

−

BAN, which gives you the WA in the BAT

References

Selection of Size Alteration Event
ETX 102 60-1030 Uen,
© Ericsson Telecom AB 1994

Plex-C 1

Chapter 6

Block Interaction

Introduction

The function blocks in AXE 10 communicate by means of signals. This chapter
covers the signal concept, the Plex statements concerning signals, and the princi
ples of addressing in the program store and job buffers.

Chapter Objectives

After completing this chapter and the related exercises you are able
to:

• describe the signal concept

• describe the different types of software signals

• write Plex-C statements for block interaction

• describe the different means of delaying signals

• describe the principles for addressing a program sequence

• describe the contents of the documents Signal Description and Sig

nal Survey

• write Plex-C statements for local signals

Figure 6.1

Chapter Objectives

What is a Signal?

Consider the call set-up in Figure 6.2. The A-subscriber lifts the handset which is
detected by the Line Interface Circuit (LIC)

➀

. All hardware devices are fre

quently and regularly scanned by simple microprocessors: the device processors
(DP). Similarly, the device processors in the LIC hardware are scanned by the
regional software, LIR

➁

. The LIR transfers the information "handset off-hook"

to its central software, LIU

➂

, which informs the Combined Junctor (CJ)

➃

. CJ

asks the Junctor Terminal (JT) to reserve a channel through the group switch for
this call

➄

. The next step is to ﬁnd out whether the subscriber has been assigned

any facilities. This information is stored in the block Subscriber Categories (SC)

➅

If the subscriber is connected to a key-set telephone, the switch reserves and con
nects a Key-Set code Receiver (KR)

➆

. The CJ orders KRU to select a free KRC

and when KRU has found this device, it orders the Time Switch (EMTS) to set up
the path between the LIC and the selected KRC

➇

. The EMTS connects the sub

scriber to the KRC device.

Plex-C 1

JTU

KRR

KRC

EMTS

TSR

TSU

CJU

SCU

LIU

LIR

LIC

KRU

HARD

ARE

SOFTW

ARE

Figure 6.2

A call set-up

Signals perform the communication between different function units. A signal is
similar to a jump from one function unit or program to another. With a signal, the
current program leaves and another program seizes the processor. The new pro
gram loads new variable values into the register memory. A signal may or may
not carry data. Since function units can only access their own variables, this is
one way to transfer variable values between function units.

Sending a signal from one function block to another means to send the signal
from the block’s CP SW unit to another block’s CP SW unit. These signals are
called CP-CP signals. Signals from a regional software unit to its central software
unit are called RP-CP signals and, likewise, signals from the central to the
regional software are called CP-RP signals (see Figure 6.3). There are some
RP-RP signals between EMRPs as well, but they are very rare and are only used
in exceptional cases.

The signal description is a document which deﬁnes the number of signal data,
type and purpose of the signal, etc. There is one signal description for each sig
nal. The signal descriptions are stored in special libraries accessible via the
SIGMA signal-handling database.

100

Block Interaction

CP-RP

RP-CP

CP-RP

RP-CP

Regional

CP-CP

Hardware

Software

Central
Software

Function Block A

Function Block B

HARD

ARE

SOFTW

ARE

Figure 6.3

The different types of software signals

A Subprogram

Most signals are a jump from a signal-sending statement in one program to a sig-
nal-receiving statement in another program. This implies that Plex programs
never execute from the beginning to the end, but usually from a signal-receiving
statement, normally ENTER, to a signal-sending statement, SEND, followed by
EXIT; see Example 51. At EXIT, the current program leaves the CP and the oper
ating system takes over. In Plex, a subprogram is the program sequence from
ENTER to EXIT.

It is possible to leave a subprogram with an EXIT and without any previous sig
nal sending statement. In this case, the job or sequence of signals terminates, and
there are no further actions.

Example 51

This example shows the structure of a Plex program and its subprograms.

Note that the CP can only execute statements inside a subprogram, i.e., between
an ENTER and an EXIT statement. For instance, the CP never executes the pro
gram line CUSELESS = 0 in the example.

101

Plex-C 1

PROGRAM; PLEX;

ENTER SIGNAL1;

....

SEND SIGNAL2;

EXIT;

ENTER SIGNAL3;

....

SEND SIGNAL4;

EXIT;

CUSELESS = 0;

ENTER SIGNAL5;

....

SEND SIGNAL6;

EXIT;

ENTER SIGNAL7;

....

EXIT;

....

END PROGRAM;

a subprogram

Figure 6.4

The structure of a CP software unit

Some Implications

When receiving a signal, the new program loads its variable values into the regis
ter memory and destroys all temporary variables of the previous program. (This is
not true for local signals, which are discussed on page 141). Since there are sev
eral call set-ups in the exchange any point in time, this also implies it is not pre
dictable when or where the program continues executing.

Since Plex-C programs do not normally execute from start to end, or in any other
order, a designer cannot assume that the program in Example 51 receives
SIGNAL1 before or after SIGNAL3, or SIGNAL4 before or after SIGNAL6.

This results in certain problems. Be very careful with stored variables, if different
subprograms read and write to them. If two or more subprograms change a stored
variable, then it may be difﬁcult to predict its current value.

102

Block Interaction

Delayed Signals

Considering that the exchange handles several calls simultaneously while the
Central Processor can only execute one program at a time, it is obvious that the
CP must queue the signals somewhere. The CP delays signals in the job buffers,
the job table, or in the time queues. Since some signals are more important than
others, the CP has four job buffers with different priorities. The job buffers are
called A, B, C and D, in which A is the one with highest priority.

These queues give rise to a real-time gap in signal handling, meaning that a cer
tain time will elapse from the moment when the signal is sent in one unit until the
moment when it is received in another one.

Different Types of CP-CP Signals

For CP-CP signals, there are different parameters describing the signal proper
ties. Three groups classify these properties and each signal has one property from
each group.

In the ﬁrst group, distinguish between unique and multiple signals, shown in
Figure 6.5. Unique signals can only be received in one particular block, while
multiple signals can go to any block. Therefore, it is necessary to specify the
receiving block by adding the address of the receiving block, the block reference,
to signal-sending statements for multiple signals. Note that it is not possible to
send a multiple signal to more than one block simultaneously.

A Multiple Signal

A Unique Signal

Unit A

Unit B

Unit C

Unit D

Figure 6.5

Unique and multiple signals

103

Plex-C 1

In Figure 6.5, the multiple signal reaches unit B, but in other cases it could be
sent to unit C or unit D.

There are no restrictions on which block may send a certain signal. If necessary,
any block can send any suitable signal; restrictions only apply to the signal
receiver as seen above.

Secondly, distinguish between direct and buffered signals, shown in Figure 6.6.
Direct signals reach the receiving block directly and immediately, while buffered
signals queue in one of the job buffers, where they wait their turn. With buffered
signals, it is not predictable when the signal reaches the receiving block. Direct
signals are similar to direct jumps to another unit. Using direct signals means that
other signals have no opportunity of coming in-between. Therefore, do not use
direct signals too often. The normal case is buffered signals.

A Direct Signal

Unit

A Buffered Signal

Job Buffer

Figure 6.6

Direct and buffered signals

Finally, distinguish between single and combined signals, shown in Figure 6.7.
Combined signals demand an immediate answer, a combined backward signal,
while single signals do not require such feedback. Therefore, combined signals
never queue in any job buffer but behave like direct jumps to another unit. When
the execution in that other unit ﬁnishes, the CP jumps back to the originating unit
with a combined backward signal.

Combined signals are always direct signals. This means that the execution contin
ues without interrupt and all other signals have to wait. Hence, use combined sig
nals restrictively in order to avoid long execution times that do not give the
operating system a chance to interfere.

104

Block Interaction

Unit

A Single Signal

Combined Signals

Figure 6.7

Single and combined signals

As mentioned before, all signals are either unique or multiple, direct or buffered,
or single or combined. Not all combinations are possible. The impossible combi
nation is combined and buffered, because combined signals are direct. Hence,
there are six types of CP-CP signals.

Signal Type

Direct

Buffered

Single

unique

✗

multiple

✗

Combined

unique

✗

multiple

✗

Figure 6.8

Possible combinations of signal types

RP Signals

For RP signals, the different types discussed in the previous section do not apply.
The CP sends RP signals over the RP bus which has other requirements; see Fig
ure 6.9.

105

Plex-C 1

CP-A

AMU

CP-B

. .

.. .

EMB

RPB

Extension Module

EMB

Extension Module Bus

Regional Processor

RPB

Regional Processor Bus

CP-A

AMU

Central Processor, A side

Automatic Maintenance Unit

Figure 6.9

The hardware structure of the CP and RPs in APZ 211

CP-RP signals have a problem ﬁnding the right RP along the RP bus. This prob
lem is solved by the distributed RP table, which is a ﬁle of records in the CP unit
storing the physical addresses to all RPs.

CP-RP signals queue in a separate job buffer, the JBR, while RP-CP signals
queue in one of the four job buffers JBA to JBD. As for CP-CP signals, the signal
description of a CP-RP signal speciﬁes the job buffer level of the signal. There
are no combined RP signals. Hence, only the statements concerning single sig
nals apply for RP signals.

Plex-C Statements for Signals

The Plex-C statements for signals divide into two groups: statements for single
signals and statements for combined signals. The syntax for the data sent with the
signal is the same in both cases. Since there are some important details concern
ing the data, the following section discusses the data types separately.

106

Block Interaction

Signal Data

Signal data are variable values sent with a signal. Signal data may consist of ﬁeld
variables, symbol variables, pointers, numerals, string objects, buffer variables
and ﬁeld expressions. In the signal sending and receiving statements, list all the
data separated by commas (,). It is not necessary, but possible, to use the same
name for a signal datum in the sending and the receiving block. It is the order of
them, not the name, that is important. The signal description speciﬁes the number
of signal data. If some of the signal data indicated in the signal description are not
relevant in a signal statement, write a plus (+) in the data list (except at the end of
the list).

Single and combined forward CP-CP signals can carry up to 25 signal data, typi
cally consisting of 16 bits. The register memory has 25 registers assigned to sig
nal data. If a signal datum has 64 bits, the maximum number of signal data is 21,
since the 64-bit signal datum occupies 4 registers.

The ﬁrst signal datum occupies the pointer register PR0. If there is a pointer
among the signal data, make sure to send that pointer as the ﬁrst signal datum.
This minimizes the amount of assembler code generated. The remaining 24 data
occupy the data registers DR0 to DR23. If there are any individual variables
among the signal data, the ﬁrst signal data should be the pointer to the record con
cerned.

For combined backward signals, the maximum number of signal data is 24, since
data register DR0 indicates which of potentially several backward signals is
returned.

For CP-RP and RP-CP signals, the maximum number of data is 13: the ﬁrst sig
nal datum is a pointer with 16 bits, and the remaining 12 data are 8 bits each.

Even though all kinds of variables, numerals, etc., mentioned above may be sent
with a signal, just a few of these data types can be used to receive signal data.
Signal data can only be received as ﬁeld variables, string variables, pointers and
buffer variables. Hence, receive constants, ﬁeld expressions, etc. as ﬁeld variables
or pointers.

Avoid sending symbol variables because they are difﬁcult to treat. Even though it
is possible to send them, they cannot be received as symbol variables or as sym
bol values. Since all symbol values translate into numbers, as discussed in Chap
ter 4, Program Sector, the signal only carries a numeric value. There is no
guarantee that the receiving block lists the symbol values for a symbol variable in
the same order. For instance, value IDLE for symbol variable STATE could be
number 1 in one SW unit, and number 5 in another. One little difference, and fatal
errors could occur. Therefore, symbol variables are not permitted in the signal
reception statement. To work around this problem, translate symbol variables into
local number symbols before sending them.

107

Plex-C 1

Single Signal Statements

Single signals initiate the execution of a program in the receiving block without
demanding a return or acknowledgment signal. The signal may be unique, i.e.,
always sent to the same block; or multiple, i.e., it may have several possible
receiving blocks. The signal can be direct or it can queue in one of the four job
buffers. Single signal statements apply to single CP-CP signals as well as to all
RP signals.

DELAY

DELAY UNTIL

BUFFER

REFERENCE

ﬁeld variable

SEND

signal name

signal datum

WITH

1..

ﬁeld variable

HURRY

;

signal name = name of single signal.

signal datum = a list of all the data that should be sent with the signal separated
by commas (,). See the section Signal Data for further details.

month day hour minute

BUFFER

numeral

ﬁeld expression

month, day, hour, minute

= the time when an absolute time-delayed signal is going

to be executed. Must be expressed as either a numeral or a ﬁeld variable.

should not be used anymore. See below for further details.

Figure 6.10

Syntax for Sending Single Signals

The signal name should describe the signal's function as clearly as possible. The
name may not be longer than 15 characters. If the signal is an answer to another
single signal, the name of the return signal should be the same as that of the for
ward signal but with an R at the end.

For multiple CP-CP signals, the REFERENCE part is mandatory. The ﬁeld varia
ble contains a block reference to the receiving block. For CP-RP signals, the
REFERENCE part is compulsory and contains the RP address. This is imple
mented by naming the address variable in the distributed RP table.

The signal description document states whether a signal is direct or buffered. See
also page 131. The signal description can have one of these texts:

108

Block Interaction

NO BUFFER.

The signal is direct. Do no longer use BUFFER in the signal

sending statement to make such a signal buffered.

LEVEL A/B/C/D BUFFER.

The signal is buffered and uses the job buffer

speciﬁed.

LEVEL A/B/C/D.

The signal is buffered and uses the job buffer speciﬁed,

unless HURRY in the signal sending statement indicates that this signal is direct.

HURRY and DELAY may be used for RP signals.

In addition to job buffers, buffered signals can be delayed using time queues. The
time queues allow to delay a signal for some time or to send it at a certain point.
The DELAY statement speciﬁes relative delays expressed in milliseconds (MS),
seconds (S) or minutes (M). For absolute delays, the DELAY UNTIL statement
speciﬁes month, day, hour, and minute when the signal reaches its destination.

Example 52

PROGRAM; PLEX;

SEND SELPIND1 REFERENCE COWNREF

WITH DEVPTR, DEVPTR:BLSTATE,

DELAY 300 MS;

EXIT;

This statement sends signal SELPIND1 to the same block, since the block refer
ence of the sending block is stored in variable COWNREF. The signal waits 300
milliseconds in the relative time queue, and then queues in the job buffer.

After the block sent this multiple signal, the program exits and all temporary var
iables and pointers lose their values.

Example 53

PROGRAM; PLEX;

SEND NEWYEAR

WITH DEVDATAP, CDATA,

DELAY UNTIL 12, 31, 23, 45;

EXIT;

This statement inserts unique signal NEWYEAR into the absolute time queue.
On December 31, at 23h45 (11:45 pm), the signal reaches the job buffer where it
has to wait some more time.

The program exits after the SEND statement.

109

Plex-C 1

Using the DELAY statement with MS, the APZ rounds off the delay time to the
nearest lower multiple of 100 ms. Thus, delays of 356 MS and 300 MS have the
same effects.

The real delay in the time queues varies between the indicated or rounded off
value to the indicated value + 100 MS, + 1 S and + 1 M. Please do not indicate the
delay time 0.

Using the DELAY UNTIL statement, set the month to 0 to delay the signal until
the indicated day, hour and minute occurs. Set the month and the day to 0 to delay
the signal until the hour and minute occurs.

Sequences including single-signal sending statements end with the statement
EXIT, which terminates the program execution and transfers control to the oper
ating system. The execution continues with the signal that has the highest prior
ity. All temporary variables and pointers lose their values after EXIT.

Note that EXIT does not necessarily have to follow directly after the signal send
ing statement. If the signal is buffered, the program can have additional signal
sending statements or even other Plex commands between SEND and EXIT.
However, this is not true for direct signals, because here the signal data would be
overridden by other Plex statements before the EXIT. The reason is that direct
signals store their data in the ordinary program registers, while buffered signals
store their data in the job buffers.

Signals may go to another block, as well as to the sending block itself.

ENTER

signal name

signal datum

WITH

1..

;

signal name = Name of single signal, the same name as in the sending statement.

signal datum = a list with of signal data that should be received. Please note that
the names of variables, numerals, etc., do not have to be the same as in the signal
sending statement. Only the order of the data is relevant. Unused data is to be
marked with a plus (+).

Figure 6.11

Syntax for Receiving Single Signals

110

Block Interaction

Example 54

This example sends and receives SIGMA, a multiple, delayed signal. See Figure
6.12.

Unit A sends SIGMA to Unit C. Unit B would have accepted the signal too. The
variable CPARTNERBLOCK of Unit A stores the block reference of Unit C.
SIGMA has three signal data and waits 200 milliseconds in the time queue.

Unit A

Unit C

Unit B

Time Queue

SEND SIGMA

REFERENCE

WITH

200MS;

ENTER SIGMA

GAMMA;

ENTER SIGMA

WITH

CPARTNERBLOCK

A, B, C,

DELAY

EXIT;

WITH ALPHA, BETA,

D, F,

Job Buffer

Figure 6.12

Sending and receiving a delayed, multiple signal

Note the plus in the signal receiving statement. Unit C ignores the third signal
datum.

111

Plex-C 1

Example 55

In this example, in Figure 6.13, Unit A sends unique signal ALPHA to Unit B.
ALPHA is a buffered signal with three signal data.

The operating system transfers ALPHA with the numeric values of the variables.
After reception of the signal, LIP equals 5, BNUM equals 7, and LIP:ANUM
equals 1. Note that the data have different names in the sending and receiving
units.

Program Store

Unit A

Unit B

DEVP=5;
DEVP:DIGIT=7;
DEVP:BSUB=1;

SEND ALPHA WITH

ENTER ALPHA WITH

LIP:BNUM,

LIP: ANUM;

ALPHA 5 7 1

JBB

JBC

JBD

Job Buffers

DEVP, DIGIT, BSUB;

EXIT;

LIP,

JBA

Figure 6.13

Sending and receiving a buffered, unique signal

112

Block Interaction

Combined Signal Statements

In contrast to single signals, combined signals demand an answer, an acknowl
edgment signal, from the receiving unit. The entry point for this acknowledgment
signal must be speciﬁed in the sending statement. There may be more than one
possible acknowledgment signal. If there are, specify entry points for all of them.
Combined signals may be multiple or unique. Combined signals are never buff
ered and behave like direct jumps. Therefore, do not place exit statements after
SEND or RETURN.

SEND

signal datum

WITH

1..

;

REFERENCE

ﬁeld variable

label

1..

characters.

signal datum = a list of all the data that is sent with the signal, separated by com
mas (,). See section Signal Data.

label

forward signal

backward signal

WAIT FOR

forward signal = name of forward signal, the signal name should not exceed 12

backward signal = name of backward signal which should be the same as for the
forward signal, but with ACK (= acknowledgment) added at the end. The number
of characters must not exceed 15.

= the name of the label at which the backward signal is to be received.

Figure 6.14

Syntax for Sending Combined Forward Signals

The REFERENCE part is mandatory for multiple signals. The ﬁeld variable con
tains the block reference of the receiving unit.

Please note that a forward signal may have more than one acknowledgment sig
nal.

The receiving unit accepts the combined forward signal with the following state
ment.

113

Plex-C 1

RECEIVE

signal datum

WITH

1..

;

ing statement.

signal datum

forward signal

forward signal = name of forward signal which must be the same as in the send

= a list of all the received signal data separated by commas. Unused

data must be marked with a plus (+).

Figure 6.15

Syntax for Receiving Combined Forward Signals

After RECEIVE, the program performs the activities initiated by the forward sig
nal and returns an answer, an acknowledgment signal. The program sends the
answer, the combined backward signal, with the following statement.

ing statement.

RETURN

signal datum

WITH

1..

;

backward signal = name of backward signal, as stated in the forward signal send

backward signal

Figure 6.16

Syntax for Returning Combined Backward Signals

Finally, the unit which sent the forward signal receives the acknowledgment sig
nal.

RETRIEVE

signal datum

WITH

1..

;

backward signal = name of backward signal which must be the same as in
the backward-signal sending statement.

backward signal

Figure 6.17

Syntax for Receiving Combined Backward Signals

Labels precede each RETRIEVE statement and mark the return point in the pro
gram. If there is more than one possible backward signal, specify one label and
one RETRIEVE statement for each signal.

Since combined signals are equivalent to direct jumps, do not place EXIT state
ments after SEND or RETURN. EXIT implies that the control is transferred to
the operating system and this is not the case with combined signals.

114

Block Interaction

Example 56

In this example, shown in Figure 6.18, unit A sends the combined signal
REQUEST with two data words to unit B. There are two combined backward sig
nals, REQUESTACK and NOREQUESTACK, for the combined forward signal
REQUEST.

SW Unit A

SW Unit B

SEND REQUEST WITH DEVP, BNUM

WAIT FOR REQUESTACK IN L10 OR

NOREQUESTACK IN L20;

L10) RETRIEVE REQUESTACK

WITH DEVP;

L20) RETRIEVE NOREQUESTACK

WITH DEVP;

RECEIVE REQUEST

WITH USERPTR, ASUB ;

IF USERPTR: STATE = IDLE THEN

RETURN REQUESTACK

WITH USERPTR;

ELSE RETURN NOREQUESTACK

WITH USERPTR;

FI ;

Figure 6.18

Signal REQUEST with backward signals REQUESTACK and NOREQUESTACK

Unit B receives the signal and returns either REQUESTACK or NOREQUEST
ACK depending on the value of the variable STATE.

115

Plex-C 1

Job Buffers and the Job Table

Signals which are not direct may be delayed using one of the following methods:

•

Job Table: sends signals at short, periodic intervals.

•

Time Queue: delays signals by a relative time speciﬁcation (relative time
queue), or an absolute time speciﬁcation (absolute time queue).

•

Job Buffer: delays a signal until all “older” jobs with the same priority level
have been processed. The most common case.

Job Buffers

Job buffers are queues following the ﬁrst in/ﬁrst out approach. This means that
the oldest job is executed ﬁrst. There are four job buffers for CP-CP and RP-CP
signals including Job Buffer A (JBA), Job Buffer B (JBB), Job Buffer C (JBC)
and Job Buffer D (JBD), where JBA is the one with the highest priority.

CP-RP signals queue in a special job buffer, JBR. The CP sends these signals to
the regional processors. The APZ 211 uses a different method not discussed here.

JBA

JBB

JBC

JBD

JBR

CP-CP and RP-CP
signals

CP-RP signals

Job buffers for

Job buffer for

Figure 6.19

The job buffers

The job buffers typically carry the following types of tasks.

JBA

urgent tasks of the operating system; preferential trafﬁc

JBB

all other telephone trafﬁc

JBC

input/output to operator and I/O devices

JBD

APZ routine self-tests

The job buffers correspond to different priority levels. The priority level of each
signal is speciﬁed in its signal description, e.g. LEVEL C BUFFER.

116

Block Interaction

Each job buffer has two pointers: Job Buffer In Pointer (JBI) and Job Buffer Out
Pointer (JBO). These pointers contain the addresses where to insert the next job
and from where to take the next job. If these pointers are equal, that is, JBO =
JBI, the buffer is empty. If not, the buffer contains a job and sends an interrupt
signal to the operating system indicating that a job is waiting.

The Job Table

The job table contains the jobs executed at short periodic intervals, for instance,
incrementing clocks for time supervision. For each job, the job table keeps a
counter proportional to the delay time, a block number for the receiving block
(BN-R), and a global signal number (GSN).

CIS

job x

COUNTER

job y

job z

job x

job y

job z

BN-R, GSN

Figure 6.20

The job table

Every 10 milliseconds, the job table receives a Clock Interrupt Signal (CIS) and
decrements all counters by one, unless the counters equal 0 or #FFFF. When a
counter reaches the value zero, the job table sends the signal, determined by its
BN-R and GSN.

Since the possible execution time after a job table signal is very short, this signal
only initiates a program sequence in the receiving block, which sets a new value
in the counter and inserts a buffered signal in one of the job buffers. The buffered
signal initiates the “real” work in the program. The scanning of the job table con
tinues with the next counter. See Figure 6.21.

117

Plex-C 1

CIS

COUNTER

BN-R, GSN

job x

job y

job z

job x

job y

job z

New Counter Value

Job Tab

the “real” w

ENTER

etc.

EXIT;

job buffer

buffered signal

Figure 6.21

Program execution from the job table

The maximum value for a counter in the job table is #FFFE. Since the counters
decrease by one every ten milliseconds, the maximum interval for periodic sig
nals is about eleven minutes.

Job table signals are inserted in the job table with Plex-C procedure
JOBTABLE INSERT. The job table counter is set to a new value with procedure
INTERVAL IS. The course Plex-C 2 discusses both procedures.

Time Queues

Time queues delay periodic and other jobs at longer intervals than the job table.
The keywords DELAY and DELAY UNTIL in the sending statement put a signal
into a time queue. There is one absolute time queue and three relative ones.

The absolute time queue, shown in Figure 6.22, stores the absolute time for signal
execution (month, day, hour, and minute). Every minute, the time queue com
pares this value to the system calendar. When there is a match, the signal moves
to one of the four job buffers.

118

Block Interaction

1 Min.

Absolute Time Queue

TQA

Job Buffer JBB

Figure 6.22

The absolute time queue (and sample job buffer JBB)

The three relative time queues, shown in Figure 6.23, have a counter for each job.
Every 100 ms, 1 second and 1 minute, respectively, the time queues receive a
periodic signal from the job table and decrement the job counters. If a counter
reaches the value zero, the time queue forwards the corresponding signal to one
of the job buffers. Again the maximum counter value is #FFFE, and the maxi
mum delay times are 109 minutes, 19 hours and 45 days, respectively.

Max 109 Min.

Max 19 H.

Max 45

100

1 s

1 Min.

Relative Time Queues

# 0150

# FFFE
# 0032

|
|
|

TQD

TQC

TQB

Days

ms.

Job Buffer JBB

Figure 6.23

The relative time queues (and sample job buffer JBB)

Job Handling

Deﬁnition of job: in Plex-C, a job is a continuous sequence of statements exe
cuted in the processor. A job begins with an ENTER statement for a buffered sig

119

Plex-C 1

nal (or with a COMMAND statement). A job ends with an EXIT statement
following the sending of one or more buffered signals.

Any job can include direct single and combined signalling statements. Therefore,
a job is not limited to one CP SW unit. Several units and blocks can take part in a
job.

Depending on their purpose and time requirements, jobs are assigned to certain
priority levels. Five different levels exist. Tasks initiated by a periodic job table
signal use the trafﬁc-handling level 1 (THL 1), JBA signals use trafﬁc-handling
level 2 (THL 2), JBB use trafﬁc-handling level 3 (THL 3), JBC use base level 1
(BAL 1) and JBD use base level 2 (BAL 2). See Figure 6.24.

JBA

JBB

JBC

JBD

THL 1

THL 2

THL 3

BAL 1

BAL 2

Job Tab

Figure 6.24

Trafﬁc-handling and basic levels

The job table has a higher priority than all the job buffers. JBA has a higher prior
ity than JBB, and so forth.

The clock interrupt signal (CIS), which is sent every 10 milliseconds, interrupts
and activates the program execution. The CIS marks the primary interval of the
CP. When the CIS arrives, the job table is scanned: all counters are decremented
by one, and when a counter reaches 0, the corresponding task is activated. Then
the jobs in the job buffers are executed in order of priority. JBA is emptied before
JBB, and so on.

If a new job enters an empty job buffer, the buffer sends an interrupt signal for
that priority level. If the ongoing job has a lower priority level, that job is inter
rupted. For example, if the CP executes a job at JBC level and an JBA interrupt
signal arrives, the JBA job does not have to wait for the next CIS but starts imme
diately. See Figure 6.25.

The data used in the waiting job stays in the register memory. THL jobs, BAL 1
jobs and BAL 2 jobs have their own set of registers (except BAL 1 and BAL 2 in
APZ 211 02, which share a common set of registers). See “AXE Central Proces
sors” on page 7.

120

Block Interaction

YES

THL 1

THL 2

THL 3

BAL 1

BAL 2

Signal ?

Signal from

JBA ?

Signal from

JBB ?

Signal from

JBC ?

Signal from

JBD ?

Run-through

of the Job

Handle Job

JBA

Handle Job

JBB

Handle Job

JBC

Handle Job

JBD

Clock

Interrupt

Tab

in Job Buffer

Figure 6.25

Scanning of the job table and the four job buffers

A job at one sublevel of THL cannot interrupt a job at another sublevel of THL,
since they share the same set of registers and the temporary variables would be
destroyed otherwise.

If a job is carried out at THL3 and a job at THL2 arrives, the job at THL3 is ﬁn
ished, and then the next job to be executed is the job from THL2 even if the JBB
is not empty.

The conclusion is that jobs from the Job Table, JBA or JBB have to wait for each
other, but all three of them can interrupt jobs from JBC and JBD. JBC jobs can
interrupt JBD jobs, except on old APZ 211 02 processors.

In Figure 6.26, a job is executing at D-level when the CIS arrives. The D-level job
interrupts immediately, and the job table starts scanning. During scanning, there
are two interrupt signals: one from B-level and one from C-level. After the scan
ning of the job table, the B-level job starts, because it has a higher priority. The
task at B-level is followed by the waiting job on C-level. Afterwards, the D-level
job can resume its execution, since there are no other jobs waiting.

A little later, the D-level job is interrupted again by an incoming interrupt signal
at B-level. During the execution of the B-level job, another interrupt signal at
JBA arrives. This job must wait, however, until the job at B-level has ﬁnished.
The job at A-level is followed by a job at C-level which in turn is interrupted by a
job at B-level having a higher priority. Finally, an incoming signal on A-level

121

Plex-C 1

interrupts the job at C-level. During the execution of this A-level job, the clock
interrupt signal is received. Nevertheless, the processing of the job table signals
has to wait until the A-level job terminates. Consequently, the (periodic) delay
times for job table tasks are not normally 100% accurate.

Time

CIS

JBB

CIS

JBB

JBA

JBC

Job execution

Paused job

JBB Interrupt

JBC Interrupt

Jobtable

A-leve

B-leve

C-leve

D-leve

JBA Interrupt

Interrupt signal

Figure 6.26

Job execution for all APZs (except APZ 211 02)

Execution Time Limits

Execution time limits always refer to jobs. A job starts when a buffered signal
enters the block. It ends when the ﬁrst EXIT is executed after sending one or
more buffered signals. Combined and direct signals do not end a job, so a job
may start and end in different blocks.

The execution time limits are identical for all APZ systems. The capacity of the
CP determines the number of assembler instructions, since different APZs exe
cute the code at different speeds. It is normally sufﬁcient to count the number of
Plex statements, if that is easier. One Plex statement is equivalent to approxi
mately 2.5 ASA statements. Note that the number of statements in a loop has to
be multiplied by the maximum number of passes through the loop!

If the largest possible execution time for a job exceeds the following limits, inter
rupt the job with a ‘phase division’ (discussed in Plex-C 2).

See page 130 for some further characteristics of the APZ 212 20 processor.

122

Block Interaction

Level

Time

Number of

ASA 210 C

instructions

Number of

Plex-C

statements

JOB TABLE

0.1 msec

~ 80

~ 30

JBA, JBB

1 msec

~ 800

~ 300

JBC

5 msec

~ 4 000

~ 1 500

JBD

50 msec

~ 40 000

~ 15 000

Figure 6.27

Execution Time Limits APZ 211 10/11

Level

Time

Number of

ASA 210 C

instructions

Number of

Plex-C

statements

JOB TABLE

0.1 msec

~ 200

~ 80

JBA, JBB

1 msec

~ 2 000

~ 800

JBC

5 msec

~ 10 000

~ 4 000

JBD

50 msec

~ 100 000

~ 40 000

Figure 6.28

Execution Time Limits APZ 212 10/11

Level

Time

Number of

ASA 210 C

instructions

Number of

Plex-C

statements

JOB TABLE

0.1 msec

~ 800

~ 300

JBA, JBB

1 msec

~ 8 000

~ 3 000

JBC

5 msec

~ 40 000

~ 15 000

JBD

50 msec

~ 400 000

~ 150 000

Figure 6.29

Execution Time Limits APZ 212 20

123

Plex-C 1

Addressing Principles

This section discusses how a signal travels from one program in the program
store (PS) via the reference store (RS) to another program in the PS. This descrip
tion follows the Rationalised Software Production concept.

The Reference Table, shown in Figure 6.30, has one area for each block. The Ref
erence Table lies in the Reference Store (RS), and it includes the Program Start
Address (PSA). The PSA contains the address for this block in the program store.

Reference

Table

Block 1

Block 2

BN-R

Block 3

PSA

PS = Program Store

PSA = Program Start Address

Block n

RS = Reference Store

s = word length -1 in RS:

s = 15 bits for APZ 211

s = 39 bits for APZ 212
BN-R = Block Number for the Receiving Block

Figure 6.30

The reference table

PSA

Signal Sending

Correction Area

One
Function
Unit

Signal Distribution

Tab

Program Code

Figure 6.31

Layout for a function unit in the program store

124

Block Interaction

The PS, shown in Figure 6.31, contains the object code for each unit. The ﬁrst
section is the signal distribution table (SDT); the second section is the signal-send-
ing table (SST); the third the program code, and the last is the correction area.
The PSA contains the address to an empty line between the SDT and SST.

•

The SDT contains the relative entry addresses to the speciﬁc program
sequences where signals are received.

•

The SST contains the global signal number (GSN) as well as other attributes.

•

The program code area contains the object code for the central software for
one function block.

•

In the correction area, all corrections made to the program, SDT or SST are
found. These corrections are made using commands.

Before taking a look at any details, consider Figure 6.32, which shows the basic
information ﬂow for sending a (unique) signal.

When unit A sends a signal to unit B, the global signal number (GSN) is found in
the SST. The GSN is used for addressing in the global signal distribution table for
unique signals (GSDT–U) which provides the block number for the receiving
block B (BN-R), and the local signal number (LSN).

The block number is used to obtain the PSA in the RS. The PSA is an absolute
address in the PS. Knowing the LSN and the PSA, the SDT in unit B can deter
mine the entry point in the program code of unit B.

The following section of this chapter discusses the different signal tables, i.e.,
SDT, SST, and GSDT in detail.

UNIT A

SST

GSN

GSDT–U

BN-R

le (RS)

UNIT B

SDT

LSN

PSA

Reference

Tab

Figure 6.32

Basic information ﬂow for sending a (unique) signal

125

Plex-C 1

Signal Tables

Signal Distribution Table (SDT)

The SDT consists of three main parts per entry:

•

instruction address (IA)

•

global signal number (GSN)

•

signal attributes

Figure 6.33 shows the layout of the SDT for the APZ 212 processor. Each entry
in the SDT, which is deﬁned by the LSN, takes 2 double words (a total of 64 bits
in the APZ 212).

The instruction address points to the corresponding signal reception statement
(ENTER signal) in the program code. Note that a signal can only be received at
one speciﬁc line in the program code of any unit.

< 4095

LSN = n

1) 2) 3)

IA (16bits)

GSN

LSN

ENTER Signal

.
.
.

3
2

PSA

2
4
6

1) Multiple or unique (1 bit)
2) Signal type (single, combined, ...) (4 bits)
3) Interaction (CP-CP, CP-RP, ...) (4 bits)

SDT

SST

Program
Code

Figure 6.33

Layout of the signal distribution table for the APZ 212

126

Block Interaction

During the initial loading of the system, all signal names are replaced by a unique
global signal number (GSN). Each signal in APT and APZ gets its own unique
GSN. The GSN is used for addressing in the global signal distribution table
(GSDT), see below.

The signal attributes give more information about the signal type as determined
by the designer. One of the signal attributes determines whether a signal is multi
ple or unique.

Signal Sending Table (SST)

The SST is used when sending a signal and consists of two main parts per entry:

•

global signal number (GSN)

•

signal attributes

Each entry in the SST, which is addressed by the signal sending pointer (SSP),
takes 1 double word. The SSP is part of the signal sending instruction in ASA.
The GSN is used to address the GSDT in which we ﬁnd the block number of the
signal receiving block (BN-R) and the local signal number (LSN). Please study
Figure 6.34 below.

PSA

1) 2) 3)

GSN

SSP = n

SST

1) Multiple / unique (1 bit)
2) Signal type (single, combined, ...) (4 bits)
3) Interaction (CP-CP, CP-RP, ...) (4 bits)

Figure 6.34

Layout of the signal sending table for the APZ 212

Global Signal Distribution Tables (GSDT)

There are two different GSDTs in the system: one for unique signals and one for
multiple signals. These tables contain block numbers and local signal numbers
for unique and multiple signals. Both tables have a size of 64 kilowords and are

127

Plex-C 1

constructed in a similar way. The global signal distribution tables GSDT-U
(unique signals) and GSDT-M (multiple signals) and associated collision tables
can be found at the beginning of the program store.

The GSDT-U is addressed with the global signal number and contains the block
number of the receiving block and the local signal number for all unique signals.

GSN =

1
2

GSDT-U

BN-R

LSN

65535

GSN

Global Signal Number

BN-R

Block Number Receiving

LSN

Local Signal Number

Figure 6.35

The global signal distribution table for unique signals in the APZ 212

Figure 6.36 shows the complete sequence of events for unit A sending a unique
signal to unit B.

128

Block Interaction

Block Interaction – Addressing with Unique Signals

.
.

SSP

LSN

.
.

BSA

PSA

BN-R=X

LSN=Z

.
.
.
.

...

SDT

Program Code

SEND Signal, ssp = 8

SST

Attributes

GSN = 130

SDT

SST

Attributes

GSN = 130

ENTER Signal

PSA

Unit A

Reference Table

(entry for Unit B)

GSDT–U

PSA

GSN = 130

65535

Program Code

BN-R = X

LSN = Z

PSA

Unit B

Figure 6.36

Addressing method for unique signals

129

Plex-C 1

The following is a short description of the sequence of events when sending a
unique signal from unit A to unit B, as shown in Figure 6.36.

After loading the software, all signal sending instructions in the machine
code have the parameter signal sending pointer (SSP). The SSP is a pointer
in the SST.

The SSP is added to the PSA to obtain the GSN (PSA + SSP

→

GSN).

The GSN is the address in the global signal distribution table for unique
signals (GSDT-U) which provides the BN-R and LSN
(GSN

→

BN-R + LSN).

The BN-R is the address in the RS, which provides the PSA for the receiv
ing block.

The PSA gives the starting point for ﬁnding the correct program sequence
in the receiving block.

The LSN for the signal is subtracted from the PSA to obtain the corre
sponding IA in the block’s signal distribution table (PSA - LSN

→

IA).

Jump to the program sequence with the signal reception statement. The rel
ative IA points to the program sequence.

Multiple Signal Sending

The addressing principle for sending a multiple signal from unit A to unit B is
slightly more complex, since the GSN alone does not determine a unique pair of
BN-R and LSN. If collisions occur, a hash or collision table is used to access all
valid pairs of BN-R and LSN. See Addressing: Multiple and RP-CP Signals on
page 299 for more details and a complete example (Appendix A).

Some APZ 212 20 Characteristics

The APZ 212 20 is the latest and most powerful AXE processor. It has been avail
able to Ericsson’s customers since 1996. The following data show some of the
characteristic features of this processor.

Memory Capacity

64 MWord program store

380 MWord data store

Max. Number of Blocks

2047

Max. Size of Block (central software unit)

64 KWord object code

Max. Number of Regional Processors (RP)

1024

Mean Time between System Failure

>> 1000 years

Call-handling Capacity

four times APZ 212 11

130

Block Interaction

Signal Documents

The two main documents for signals are the signal description and the signal sur
vey.

Content of a Signal Description

The signal description (SD) is a document that deﬁnes a signal. SDs are Plex-C
source code documents, too. All SDs are stored in libraries such as APTSIGLIB.
There are more than 50,000 signals in AXE today. Therefore, try to use existing
signals instead of creating new ones in design work.

Figure 6.37 shows the SD for the single, multiple CP–CP signal ADTINIT. The
SD includes the following items:

•

name of the signal

SIGNAL ADTINIT

•

signal number (comment)

! 98/15514-ANZ 211 12 REV. D !

•

function (comment)

! FUNCTION . . . !

•

signal type

TYPE IS 1 MULTIPLE CP –CP

The signal type can be 1, 2 or 3. Type 1 marks single signals. Types 2 and 3 indi
cate combined forward and combined backward signals, respectively.

MULTIPLE indicates that this is a multiple signal. Unique signals have no indi
cation at this point.

CP–CP states that this is a CP–CP signal. Other alternatives are CP–RP and RP–
CP.

•

possible return signal (comment)

! ADTINITR !

•

possible sending block (comment)

! AFCO !

•

possible receiving block (comment)

! AUDIT FUNCTION HANDLER !

Note that these block names may be examples only, while lots of other blocks
might send or receive this signal too.

•

buffer level

LEVEL C BUFFER

ADTINIT's function is to analyse an I/O command. Consequently the signal is
put into job buffer C.

•

signal data

DATA D1 16 etc.

This signal carries ﬁve data words, each of 16 bits. The data deﬁnition is followed
by a mandatory, detailed data description in a comment.

•

ID sector

ID ADTINIT TYPE DOCUMENT
etc.

131

Plex-C 1

DOCUMENT ADTINIT;

SIGNAL ADTINIT;

! 98/15514-ANZ 211 12 REV. D !

! FUNCTION: ANALYZING OF START REQUESTING COMMAND,

ANALYZING OF PARAMETERS AFTER PARAMETER TEST !

TYPE 1 MULTIPLE CP-CP;

! MULTIPLE SIGNAL !

! POSSIBLE RETURN SIGNAL:

ADTINITR !

! COMMUNICATION: SENDER:

AFCO

RECEIVER:

AUDIT FUNCTION HANDLER !

LEVEL C BUFFER;

DATA D1 16,

! USER’S POINTER !

D2 16,

! AUDIT FUNTION, TEST NUMBER !

D3 16,

! AUDIT FUNCTION, SUBTEST NUMBER (NOT USED) !

D4 16,

! COMMAND CODE !

D5 16;

! IOPTR !

! DETAILED DATA DESCRIPTION:

D2 SEE SIGNAL ADTEXIST

D3 SEE SIGNAL ADTEXIST (ALL TEST DO NOT HAVE SUBTESTS)

D4 = 0 GIVEN COMMAND IS ’INITIATION OF TEST’ (AFETI, AFTSI)

> 0 FOR FUTURE USE

! MISCELLANEOUS INFORMATION: !

END SIGNAL;

END DOCUMENT;

ID ADTINIT TYPE DOCUMENT;

CLA 98/15514;

NUM ANZ 211 12;

REV D;

DAT 89-09-11;

DES EUA/ZBD MCN;

RES EUA/ZBD;

APP EUA/ZBD;

END ID;

Figure 6.37

Signal description for ADTINIT: a single, multiple signal

Note that the operating system never truncates data sent with a sig
nal to the bit size speciﬁed in the SD. Depending only on the regis
ter size, the signal uses 16 or 32 bits for each item of signal data, in
order to reduce the execution time.

The ID sector divides the document number into the decimal class
(CLA) and the article code (NUM). The ID sector also shows the

132

Block Interaction

revision state (REV), the designer (DES), the department responsible for the
design (RES), and the approving department (APP).

The following statements describe the buffer level of a signal.

•

NO BUFFER : the signal is direct. A job buffer level may not be speciﬁed.
Signals marked with NO BUFFER must not have DELAY or BUFFER in the
signal sending statement.

•

LEVEL A/B/C/D : the signal is queued at the buffer level speciﬁed, except
when HURRY is added in the signal sending statement.

•

LEVEL A/B/C/D BUFFER : the signal is buffered, even if HURRY is added
in the SEND statement.

Figure 6.38 shows the SD for the unique, combined forward signal BUFTOBUF.

DOCUMENT BUFTOBUF;

SIGNAL BUFTOBUF;

! 1/15514-CNZ 211 160 REV. A !

! FUNCTION: SIGNAL USED DURING LOADING OF CONVERSION TABLES

IN BLOCK FCD. A BUFFER LOADED WITH LOADING

INFORMATION IS RESHAPED TO AN APPROPRIATE FORM

FOR FCD TO MAKE UP THE CONVERSION TABLES !

TYPE 2 CP-CP;

! COMBINED FORWARD SIGNAL!

! POSSIBLE RETURN SIGNAL:

BUFTOBUFACK !

! COMMUNICATION: SENDER:

FCD

RECEIVER:

FCD !

RETURN BUFTOBUFACK;

DATA D1 B;

! BUFFER!

END SIGNAL;

END DOCUMENT;

ID BUFTOBUF TYPE DOCUMENT;

CLA 1/15514;

NUM CNZ 211 160;

REV A;

DAT 87-12-07;

DES EUA/ZBK ABC;

RES EUA/ZBKC;

APP EUA/ZBKC;

END ID;

Figure 6.38

Signal description for the combined forward signal BUFTOBUF

BUFTOBUF is a combined forward signal; consequently, it is a TYPE 2 signal.
The RETURN statement is only used by combined signals deﬁning the name of
the return or acknowledgement signal. The SD in Figure 6.38 shows that
BUFTOBUFACK is the combined backward signal to forward signal BUFTO
BUF.

133

Plex-C 1

If several acknowledgment signals exist, list the combined backward signals as in
this example:
RETURN CBSIG1ACK, CBSIG2ACK, CBSIG3ACK;

Please omit the statements NO BUFFER / LEVEL A/B/C/D in SDs for combined
signals. These signals are always direct.

Figure 6.39 shows the SD for the return signal to BUFTOBUF, the combined
backward signal BUFTOBUFACK.

DOCUMENT BUFTOBUFACK;

SIGNAL BUFTOBUFACK;

! 2/15514-CNZ 211 160 REV. A !

! FUNCTION: RETURN SIGNAL USED DURING LOADING OF CONVERSION

TABLES IN BLOCK FCD. A BUFFER LOADED WITH LOADING

INFORMATION IS RESHAPED TO AN APPROPRIATE FORM

FOR FCD TO MAKE UP THE CONVERSION TABLES !

TYPE 3 CP-CP;

! COMBINED RETURN SIGNAL!

! RETURN SIGNAL TO:

BUFTOBUF !

! COMMUNICATION: SENDER:

FCD

RECEIVER:

FCD !

RETURN AS 0;

DATA D1 B;

! BUFFER!

END SIGNAL;

END DOCUMENT;

ID BUFTOBUFACK TYPE DOCUMENT;

CLA 2/15514;

NUM CNZ 211 160;

REV A;

DAT 87-12-07;

DES EUA/ZBK ABC;

RES EUA/ZBKC;

APP EUA/ZBKC;

END ID;

Figure 6.39

Signal description for the combined backward signal BUFTOBUFACK

Since BUFTOBUFACK is a combined backward signal, it is marked as a TYPE 3
signal. The possible return signals for a forward signal are numbered internally,
using the statement RETURN AS 0, where 0 is the ﬁrst possible internal number.

134

Block Interaction

Descriptions for CP-RP and RP-CP Signals

SDs for RP signals are similar to those for CP-CP signals. Figure 6.40 shows the
SD for the CP-RP signal ALARMEXRP, and Figure 6.41 shows the SD for the
RP-CP signal RPHWFAULT.

DOCUMENT ALARMEXRP;

SIGNAL ALARMEXRP;

! 194/15514-ANT 212 06 REV. A !

! FUNCTION: EXERCISE ALARM CIRCUITS IN SSPU !

TYPE 1 CP-RP;

! SINGLE SIGNAL!

NUMBER IS 86;

! POSSIBLE RETURN SIGNAL:

RPALARMEXEXR !

! COMMUNICATION: SENDER:

RECEIVER:

BT !

LEVEL C;

DATA D1 16,

! RECEIVING INDIVIDUAL !

D2 8;

! UNIT AND TESTCASE !

! DETAILED DATA DESCRIPTION:

D2 B0-B2: TEST CASE

B3-B5: UNIT

B6=1

INDICATES TEST FUNCTION

B7=1

INDICATES ORDER !

END SIGNAL;

END DOCUMENT;

ID ALARMEXRP TYPE DOCUMENT;

CLA 194/15514;

NUM ANT 212 06;

REV A;

DAT 83-02-15;

DES LMF/SKG TEN;

RES XT/RKEC;

APP XT/RKLC;

END ID;

Figure 6.40

SD for the CP–RP signal ALARMEXRP

The CP-RP signal has one new statement: NUMBER IS 86. This is an internal
number in the CP-RP interface. The block designer is sequentially numbering all
CP-RP signals in one block beginning with number 1.

Note also that the ﬁrst signal datum has 16 bits while the other datum has only 8
bits.

RP-CP signal descriptions include the SIGNAL GROUP statement, for instance,
SIGNAL GROUP ETRSSRPSIG. The signal group name corresponds to a
number in addressing the CP program in the program store. The signal group

135

Plex-C 1

number is shared by all signals sent by the RP SW unit to the CP SW unit of the
same block. These signals are grouped in the signal distribution table (SDT) of
the CP SW unit. See “Addressing for RP-CP signals” on page 298. The advantage
of this concept is that RP and CP software units can be compiled independently
without knowing each other’s signal tables.

DOCUMENT RPHWFAULT;

SIGNAL RPHWFAULT;

! 12/15514-CNT 211 1072 !

! FUNCTION: A HW FAULT HAS CEASED/APPEARED IN THE ETC!

TYPE 1 MULTIPLE RP-CP;

!SINGLE SIGNAL!

! COMMUNICATION: SENDER:

RECEIVER:

ET !

LEVEL C;

SIGNAL GROUP ETRSSRPSIG;

DATA D1 16,

! RECEIVING INDIVIDUAL !

D2 1,

! FAULT SITUATION !

D3 2;

! INDIVIDUALS CONCERNED !

! DETAILED DATA DESCRIPTION:

D2 = 0 A HARDWARE FAULT HAS CEASED IN THE ETC

1 A HARDWARE FAULT HAS APPEARED IN THE ETC

D3 = 0 ALL INDIVIDUALS CONCERNED

1 INDIVIDUALS 1-8 CONCERNED, IN ETC 24/96

2 INDIVIDUALS 9-16 CONCERNED, IN ETC24/96

3 INDIVIDUALS 17-24 CONCERNED,IN ETC24/96

END SIGNAL;

END DOCUMENT;

ID RPHWFAULT TYPE DOCUMENT;

CLA 12/15514;

NUM CNT 211 1072;

REV A;

DAT 84-01-17;

DES XT/ULG SJAS;

RES XT/ULGC;

APP XT/ULGC;

END ID;

Figure 6.41

SD for the RP–CP signal RPHWFAULT

136

Block Interaction

R Variables and Signal Descriptions

R variables may not be sent in a signal datum of length 16 bits. Instead use a sig
nal datum with the properties R or T. R signal data has 16 or 32 bits depending on
the APZ.

R signal data can contain an R variable. The receiver must declare the receiving
variable as an R variable, otherwise the compiler will issue a warning message.

Since some signals that have been updated to include R signal data are used by
hundreds of blocks, it would consume too many resources to modify all receiving
blocks accordingly. The T property for signal data avoids this inconvenience.

T signal data may contain an R variable, but it is possible to receive the data in a
variable that is not an R variable. The value sent with the signal will be truncated
to the number of valid bits in the receiving variable.

Example 57

Suppose that CP software unit A contains a ﬁle greater than 64k, with the R-
pointer DEVDATAP.

CP software unit B is an old program using a 16-bit variable TUSERPTR.

Unit A sends signals RINFO (Figure 6.42) and TINFO (Figure 6.43) to unit B.

RINFO

! USER POINTER !

16; ! SPARE !

TINFO

T , ! USER POINTER !

16; ! SPARE !

137

Plex-C 1

UNIT A

UNIT B

DECLARE;

....

POINTER DEVDATAP

(DEVDATA) R;

....

END DECLARE;

PROGRAM; PLEX;

....

SEND RINFO

WITH DEVDATAP,0;

....

END PROGRAM;

DECLARE;

....

VARIABLE

TUSERPTR;

....

END DECLARE;

PROGRAM; PLEX;

....

ENTER RINFO

WITH TUSERPTR,+;

....

END PROGRAM;

Result:

The compiler will issue a warning at compilation.

Figure 6.42

Sending an R pointer as R signal data

Figure 6.43 shows the same situation using a signal with a T signal datum.

UNIT A

UNIT B

DECLARE;

....

POINTER DEVDATAP

(DEVDATA) R;

....

END DECLARE;

PROGRAM; PLEX;

....

SEND TINFO

WITH DEVDATAP,0;

....

END PROGRAM;

DECLARE;

....

VARIABLE

TUSERPTR;

....

END DECLARE;

PROGRAM; PLEX;

....

ENTER TINFO

WITH TUSERPTR,+;

....

END PROGRAM;

Result:

no error or warning at compilation.

Figure 6.43

Sending an R pointer as T signal datum

138

Block Interaction

Content of a Signal Survey

The signal survey (SS) lists all signals that the unit receives and sends. Create an
SS for all CP and EMRP software units with product classes CAA 107 and CAA
117. The SS is usually listing all signals in alphabetic order. It includes external
and internal signals. Signals between RP and CP or EMRP and CP software units
are included as internal signals.

The ﬁrst line indicates the name of the unit. For a CP software unit, the line reads
DOCUMENT C7ST2USURVEY, for example. The corresponding EMRP soft
ware unit would begin with the line DOCUMENT C7ST2RSURVEY.

The block name is speciﬁed in the line USE BLOCK C7ST2. The following is a
list of all the signals. The name and the document number are stated for each sig
nal. There are also letters that indicate their direction and type. Direction S means
that the signal is sent, R that it is received and T that it is both sent and received.
The following table lists possible signal types.

Signal Type

Description

Combined Backward signal
(received or sent, type 3)

Signal from RP to CP

EMC

Signal from EMRP to CP

Signal from CP to RP

CEM

Signal from CP to EMRP

For RC, EMC, CR and CEM signals, the direction can be omitted.

For CP-RP signals the same number as in the statement NUMBER IS in SD is
stated at the end of the line, for example, number 1 for the signal
C7COUNTREQRP. For RP-CP signals this number and the signal group, which
has been indicated in the SD with the statement SIGNAL GROUP, are stated at
the very end.

The signal survey ends with the ID sector with the same contents as the ID sector
of the SD.

If the program (SPI) is analysed with the SS, the tool fetches all listed signals
from libraries and compares stated the contents of the SDs, SS and SPI. The Plex
compiler needs the SS to ﬁnd and fetch signals from signal libraries into the com
piler. Figure 6.44 shows the SS for CP software unit C7ST2U.

The signal-handling database SIGMA automatically generates SS documents for
a SW unit, provided that the design project stored proper Function Framework
documents in SIGMA.

139

Plex-C 1

DOCUMENT C7ST2USURVEY;

SIGNALSURVEY;

USE BLOCK C7ST2;

!----------------------------------------------------------!

! RECEIVED AND SENT SIGNALS

!----------------------------------------------------------!

CONTINUEC

, 707/15514 - APZ 210 ;

C7DISCRMSU

, 57/15514 - ANT21810 ;

!----------------------------------------------------------!

! RECEIVED SIGNALS

!----------------------------------------------------------!

CONTFS

, 666/15514 - APZ210

;

CLTIME0

, 600/15514 - APT210

;

C7CHECKST

, 91/15514 - ANT21810 ;

C7COUNTREQ

, 100/15514 - ANT21810 ;

C7RPALIGNFAIL ,

RC , 20/15514 - CNT2182501, 0 MTP2RPSIG ;

C7RPCOUNTINFO ,

RC , 21/15514 - CNT2182501, 1 MTP2RPSIG ;

C7SLINQACK

,R CB , 103/15514 - ANT21810 ;

C7STARTST

, 104/15514 - ANT21810 ;

!----------------------------------------------------------!

! SENT SIGNALS

!----------------------------------------------------------!

CONTFSEND

, 667/15514 - APZ210

;

C7ALIGNFAIL

, 90/15514 - ANT21810 ;

C7ALIGNRPO

, 105/15514 - ANT21810 ;

C7CHECKSTACK

,S CB , 92/15514 - ANT21810 ;

C7COUNTINFO

, 99/15514 - ANT21810 ;

C7COUNTREQRP

CR ,

1/15514 - CNT2182501,

C7DELSTR

, 249/15514 - ANT21810 ;

C7DISCRMSUS

, 59/15514 - ANT21810 ;

C7EMERPOVRP

CR ,

2/15514 - CNT2182501,

C7EMINFO

, 94/15514 - ANT21810 ;

C7SLINQ

, 102/15514 - ANT21810 ;

END SIGNALSURVEY;

END DOCUMENT;

ID C7ST2USURVEY TYPE DOCUMENT;

CLA 15514;

NUM CAA 107 3376;

REV C;

DAT 90-08-02;

DES ETL/XD/NGD NOLAN;

RES ETL/XD/NGDC;

APP ETL/XD/NGT;

END ID;

Figure 6.44

Signal survey for CP software unit C7ST2U

140

Block Interaction

Local Signals

Local or sector signals are internal signals. Their behaviour is very similar to that
of a GOTO statement. Use local signals inside the Plex program sector or
between the Plex program sector and an assembly language sector (Chapter 7,
Call Routines, describes the assembly language sector). Implement local signals
with the following statement.

TRANSFER

signal name

signal datum

WITH

1..

;

signal name = The name of the signal.

signal datum = List of all signal data. See section Signal Data
this chapter for more details.

at the beginning of

Figure 6.45

Syntax for Sending Local Signals

This statement results in a direct jump to the receiving Plex or assembly language
sector (ASA sector). In the ASA sector, insert the assembler instruction
RECEIVE to deﬁne the entry point. In the Plex sector, insert the statement
ENTRANCE, see below. Local signals from an assembly language sector or
another branch of the Plex sector are received in the Plex program sector with the
following statement.

ENTRANCE

signal name

signal datum

WITH

1..

;

signal name = The name of the signal.

signal datum = List of all signal data. See section Signal Data
this chapter for more details.

at the beginning of

Figure 6.46

Syntax for Receiving Local Signals

The statement implies a direct jump from the ASA sector (sending statement
SSIN) or the Plex program sector (sending statement TRANSFER) to the Plex
program.

Place signal descriptions for local signals after the data sector at the end of the
program. In the signal description, add the word LOCAL after TYPE. LOCAL
implies that the signal is not transferred via the signal distribution table but
implemented as a direct jump to a Plex or assembly language sector.

141

Plex-C 1

Example 58

Figure 6.47 shows the signal description for local or sector signal IMGRNE in
CP software unit MRNAU.

DOCUMENT MRNAUPROGRAM;

....

DATA;

....

END DATA;

SIGNAL IMGRNE;

! 001/15514-CAA 107 8861 !

! FUNCTION: SEIZE IDLE COMMAND INDIVIDUAL !

TYPE 1 CP-CP, LOCAL;

! POSSIBLE RETURN SIGNAL: - !

DATA D1 16,

D2 16;

END SIGNAL;

....

END DOCUMENT;

ID MRNAUPROGRAM TYPE DOCUMENT;

....

Figure 6.47

Signal description for local signal IMGRNE included in the SPI for SW unit
MRNAU

A simple GOTO statement could replace a local signal in a Plex program sector.
Nevertheless local signals are common, if the block is designed according to the
state transition model which is discussed in the course AXE Design Project.

Sending a local signal to an assembler sector is equivalent to a direct jump. Since
the DECLARE sector is common to the Plex and ASA sectors, the variables and
symbol constants available to the Plex sector are also available to the ASA sector.
Temporary variables, for instance, can be used in their register position in certain
assembler instructions. Furthermore, the ASA sector will receive the local signal
data in the registers PR0, DR0, DR1, etc.

142

Block Interaction

Example 59

The example in Figure 6.48 shows the interaction between the Plex program and
an ASA sector.

Sending and Receiving Local Signals

DOCUMENT SAMPLEUPROGRAM;

....

END DECLARE;

PROGRAM; PLEX;

....

TRANSFER ADD WITH CNUMBER, CVALUE;

....

ENTRANCE RESULT WITH SUM;

....

END PROGRAM;

PROGRAM SUM;

ASA210C;

....

RECEIVE ADD;

MFR AR0-PR0;

MFR AR1-DR0;

AR AR0-AR1;

MFR PR0-AR0;

SSLN RESULT;

END PROGRAM;

END DOCUMENT;

ID SAMPLEUPROGRAM TYPE DOCUMENT;

....

Figure 6.48

Signalling between the Plex and ASA sectors

143

Plex-C 1

Chapter Summary

This chapter discussed the various types of signals.

Unique signals always go to the same block, while multiple signals can be
received in several blocks.

Single and multiple signals are either direct or buffered. Direct signals reach the
target block without any delay, while buffered signals queue in one of the four job
buffers.

Combined signals are always direct and demand an acknowledgment signal
(combined backward signal).

The job table stores periodic signals with a short waiting time. The absolute and
relative time queues handle signals delayed by an absolute or a relative time.

Addressing a program sequence involves the global signal distribution table and
the reference table.

Each signal is described in its signal description.

The signal survey is a list of all the signals that a function unit receives and sends.

Local signals are internal signals. They may be sent within the Plex program sec
tor, or between the Plex program sector and an assembly language sector.

References

[1]

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

Software Reliability Handbook
EN/LZG 205 603,
© Ericsson Telecom AB 1998

CPS Principles (for APZ 211 11)
1/1551-ANZ 211 41 Uen,
© Ericsson Telecom AB 1993

Execution Time Limits
ETX 102 60-1026 Uen,
© Ericsson Telecom AB, ETX/TX, 1997

Updating of Signal Descriptions for R Variables
ETX 102 60-1062 Uen,
© Ericsson Telecom AB, ETX/TX, 1993

144

Chapter 7

Call Routines

Introduction

Call routines are pieces of program code which have a certain name, they are
often called at several places in the software.

The software designers can create their own call routines, these are called subrou
tines. There is also a library of standard call routines, the procedures.

This chapter describes the statements for calling these routines and how to write
statement blocks.

Chapter Objectives

After completing this chapter, you are able to:

• describe the differences between statement blocks, assembly lan

guage sectors, and procedures

• write Plex-C statements for subroutines and procedure calls

• know the difference between a block number and a block reference

Figure 7.1

Chapter Objectives

Overview

There are three types of call routines. Unit designers write their own subroutines,
while procedures are ready-made extensions of the Plex-C programming lan
guage. Plex-C divides subroutines into statement blocks (written in Plex) and
assembly language sectors.

Call Routine

Subroutine

Procedure

Statement Block

Assembly

Language Sector

Figure 7.2

Call routines

145

Plex-C 1

Subroutines

Imagine that a program sequence is to be used often in a program. Instead of
repeating this sequence in several places in the program, it is better to put it in a
subroutine. Whenever the program sequence is needed, the code calls the subrou
tine, which is then executed.

Subroutines make programs easier to read. Please note the difference between
subroutines and subprograms. A subprogram includes all program text between
an ENTER and an EXIT statement. See Chapter 6, Block Interaction, for details.

There are two types of subroutine:

•

statement block

•

assembly language sector

A statement block is a subroutine using Plex. An assembly language sector is
consists of ASA code.

Statement Block

The syntax for statement blocks is very simple. There are no input or output
parameters.

BEGIN

statement block name ;

sequence of statements

END

statement block name ;

Figure 7.3

Syntax for Statement Blocks

All statements except EXIT, RECEIVE, ENTER, ENTRANCE and TRANSFER
are allowed in a statement block.

Programs call a statement block with the DO statement.

statement block name ;

Figure 7.4

Syntax for Statement Block Calls

It is not possible to call a statement block from another SW unit or another pro
gram sector.

146

Call Routines

Restrictions

It is possible to call one statement block from another one. But this may be difﬁ
cult to follow and may not be a good idea. It is not permitted to jump to a label in
a statement block from a statement outside of it, or to jump from a statement
block to a label outside of it.

Calling a statement block requires some execution time. Therefore a statement
block should only be used, if this code is really needed several times in the pro
gram, and the readability is increased by using the statement block. The use of
statement blocks is much more restricted than in other programming languages,
and subroutines in Plex do not have any input or output parameters.

According to design rules, all statement blocks should be placed at the end of the
program sector.

Example 60

This example calls and declares a brief statement block.

001

DOCUMENT SAMPLEUPROGRAM;

....

150

PROGRAM; PLEX;

....

420

DO SUM;

....

720

BEGIN SUM;

721

CSUM = CMAX + CMIN;

722

CMAX = CSTART;

723

END SUM;

724

END PROGRAM;

....

statement block call

statement block

Figure 7.5

Statement Block

On line 420, the program calls the statement block SUM. This call results in a
jump to line 720 where the statement block starts. The execution continues to line
723, which is the end of the statement block.

When the execution of the statement block has ﬁnished, the processor executes
the statement after the DO statement.

Assembly Language Sector

An assembly language sector is called with the same statement (DO) as a state
ment block.

147

Plex-C 1

An assembly language sector is an additional program sector, written in ASA
code and placed after the Plex program sector. As for statement blocks, the pro
gram execution continues with the statement after the DO statement, when the
assembly language sector has ﬁnished executing.

Example 61

This example shows the call to a program sector written in ASA 210 C.

001

150

420

719

720

721

722

723

724

725

726

727

DOCUMENT SAMPLEUPROGRAM;

....

PROGRAM; PLEX;

....

DO SUM;

....

END PROGRAM;

PROGRAM SUM;

ASA210C;

RS WR1-CNUM;

RS AR0-CMAX;

AR WR1-AR0;

WS CRESULT-WR1;

END PROGRAM;

END DOCUMENT;

....

ASA sector call

ASA sector

Figure 7.6

ASA Sector

No Restrictions

The restrictions on statements in statement blocks do not apply to the assembly
language sectors.

Assembly language sectors are popular when optimising Plex-C programs to
accelerate the trafﬁc handling in the exchange.

Procedures

Procedures are an extension of the Plex-C language. All procedures are written in
ASA code, allowing access to speciﬁc registers in the CPU. The designer does
not need to write the program sequence to reach such a register. The program
simply calls the procedure.

Another advantage of using procedures is that they increase readability. It is not
always necessary to know the solution to a problem and the solution’s implemen
tation. The idea is that a Plex programmer should not need to be competent in

148

Call Routines

programming in assembly language. Procedures are stored in the library CPRO
CLIB.

The Plex-C Language Description includes a list of all available procedures.
There is a description of each procedure, explaining how to write statements
using the procedure.

Call to a Procedure

All procedures use only temporary variables. The following frame contains the
syntax for calling the procedures LOADREF and TRANSFORM.

LOADREF

temp 1 ;

BLOCKNUMBER IN TEMP

temp 2

TO BLOCKREF

TRANSFORM

BLOCKREF IN TEMP

temp 3

TO BLOCKNUMBER

IN TEMP

temp 4 ;

temp 1, temp 2, temp 3, temp 4 = temporary variables

Figure 7.7

Syntax for the procedures LOADREF and TRANSFORM

The procedure LOADREF fetches the block reference of the current block and
stores it in temporary variable temp 1.

The procedure TRANSFORM translates block reference into block number, and
vice versa. For instance, if the block number is stored in temp 2, the procedure
transforms it into the corresponding block reference and stores it in temp 4. The
variable temp 2 is left unchanged. See page 150 for the difference between block
reference and block number.

149

Plex-C 1

Example 62

This example demonstrates calling the procedures LOADREF and TRANS
FORM.

DOCUMENT SAMPLEUPROGRAM;

....

PROGRAM; PLEX;

....

LOADREF TOWNREF;

TRANSFORM BLOCKREF IN TEMP TOWNREF TO

BLOCKNUMBER IN TEMP TOWNBLNO;

....

COWNREF = TOWNREF;

COWNBLNO = TOWNBLNO;

....

END PROGRAM;

Figure 7.8

Calling Procedures

In the example, the reference of the current block is stored in the variable TOWN
REF with procedure LOADREF. Then the procedure TRANSFORM translates
the block reference into the block number.

In order not to lose these values at the next EXIT statement, it is a good idea to
save them in stored variables such as COWNREF and COWNBLNO in this
example.

After compilation of the program, the statements belonging to the procedure are
inserted either in the place for the call, or placed as a subroutine at the end of the
program.

Block Number and Block Reference

Today the system uses both block number and block reference to identify a block.

•

The block number addresses the block as an entry in the reference table of
the reference store.

•

The block reference appears in multiple signal sending statements (SEND
signal REFERENCE block reference ...).

This section explains the difference between these two and their origins.

The ﬁrst AXE 10 systems had a maximum of only 255 blocks and 255 signal
groups. Each block was identiﬁed by a unique word (16 bits). The word consisted
of the block number in halfword 1 and the signal group number in halfword 0.
This word was called the block reference.

150

Call Routines

With further development of the AXE 10 system, the signal group numbers were
dropped from the block reference, and halfword 0 was left empty.

Then the maximum number of blocks was increased to 4095. The block number
had to grow to 12 bits. The block reference changed as follows:

•

halfword 1 of the block reference contains the eight least signiﬁcant bits of
the block number

•

bits 0 to 3 of halfword 0 contain the four most signiﬁcant bits of the block
number

•

bits 4 to 7 of halfword 0 are empty

Example 63

This example shows the block reference and the block number for a typical func
tion block.

Block Number

Block Reference

halfword 1

halfword 0

Figure 7.9

Block number and block reference

In the example, the block number (BN) is 1067 or # 42B. The block reference is
# 2B04 or decimal 11012 accordingly.

151

Plex-C 1

Chapter Summary

Remember these points from this chapter:

•

the difference between a statement block, an assembly language sector and a
procedure

•

how to write and call a statement block

•

how to call an assembly language sector and a procedure

•

the exchange uses both block number and block reference to identify a block

References

[1]

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

152

Chapter 8

Input and Output Statements

Introduction

An AXE exchange needs to communicate with its environment. This chapter cov
ers the I/O statements to send and receive information in the exchange.

Chapter Objectives

After completing this chapter and the exercises for it, you are able to:

• describe the differences between alphanumeric and ﬁle-oriented

input/output

• write Plex-C subprograms for alphanumeric input/output

Figure 8.1

Chapter Objectives

Alphanumeric and File-oriented Input/Output

The exchange communicates with the operation and maintenance (O&M) staff.
Consider these typical situations:

•

An exchange technician changes subscriber categories, replaces devices or
connects new subscribers.

•

The exchange informs the O&M staff of important events, for example if an
RP is blocked due to a fault.

•

Input/output includes certain routine tasks too, for example, dumping data on
a hard disk.

Figure 8.2 shows the different I/O devices connected to the exchange. I/O devices
include personal computers or UNIX workstations, hard disk drives or magnetic
tape drives.

The I/O system administers the two-way communication between the AXE
exchange and its environment via the I/O devices. Currently, Ericsson delivers
two different I/O systems, the IOG-11 and the more modern IOG-20.

153

Plex-C 1

AXE 10

I/O System

DL = Data Link

HD = Hard Disk

OD = Optical Disk

AL = Alarm Panel

FD = Flexible Disk

MT = Magnetic Tape

CD = CD - ROM

AT = Alphanumeric Terminal

Figure 8.2

An AXE 10 exchange with some I/O devices

The I/O system supports two types of data transport:

•

Alphanumeric transport, which is the transportation of small quantities of
data, for example, commands and printouts.

•

File-oriented transport, which is the transportation of larger data units, for
example, storage of charging data on a hard disk or loading of a new function
block.

For details on ﬁle-oriented I/O statements, see Appendix B on page 309.

Input Output

Data Transport

Alphanumeric I/O

File-oriented I/O

Figure 8.3

Two types of data transport and I/O handling

I/O devices for alphanumeric data are alarm and hard copy printers, display units,
UNIX workstations, and personal computers.

154

Input and Output Statements

I/O devices for ﬁle-oriented data are magnetic tape drives, hard disks and ﬂexible
disks.

Data links handle remote data transport. The data link can carry alphanumeric
data to or from a remote terminal. It can also carry ﬁle-oriented data, such as
charging data, to an administrative centre.

Function blocks that receive or send information via the I/O system are called
user blocks.

Before communicating with an I/O device, the Plex program has to seize the
device. This guarantees exclusive access to the device. Likewise, when the com
munication ends, the Plex program has to release the device.

Statements for Alphanumeric Input/Output

To write statements in user blocks for sending or receiving information from I/O
devices, it is helpful to understand the structure of the I/O system and how it com
municates with the user blocks. Figure 8.4 shows the interaction between the I/O
system and one of the user blocks.

All I/O devices connect to a support processor. In Figure 8.4, there is only one I/
O device, but in reality a number of devices of different types connect to each SP.

The I/O system contains a number of analysis and line buffers. When seizing an I/
O device, the I/O system assigns a free line buffer and a free analysis buffer to
this device. These buffers temporarily store the I/O text. The analysis buffer han
dles input from the I/O device, and the line buffer handles output. As Figure 8.4
shows, the user blocks have direct access to the buffers and can read information
from the analysis buffers and write into the line buffers.

The line buffer can store a maximum of 72 characters and the analysis buffer 144
characters. The I/O system administers the interaction between the buffers and
the relevant I/O device.

There are four basic Plex statements for transferring information between the
buffers and the I/O device, and between the buffers and the user block. Figure 8.4
shows these four statements.

•

the FETCH statement transfers information from the analysis buffer to the
user block.

•

the INSERT statement transfers information from the user block to the line
buffer.

•

the WRITE statement orders the I/O system to print out the text in the line
buffer to an I/O device.

•

the READ statement transfers information from the I/O device to the analy
sis buffer.

155

Plex-C 1

Read

I/O System

User

Analysis Buffer
144 Characters

Fetch

Insert

Write

Line Buffer
72 Characters

Program Store

Block

Figure 8.4

Interaction between I/O system and a user block

The following sections describe how to write these and some other I/O state
ments.

Command Receiving Statement

Typically, I/O communication starts with the operator entering an exchange com
mand, such as

SULII

in .

Example 64

SULII:DEV=LI2-37,SNB=123450&123451;

command name

argument

parameter

argument

parameter block

Figure 8.5

Elements in an exchange command

SULII is an acronym for subscriber line initiate. The command has the parame
ters DEV (device) and SNB (subscriber number). The example connects sub
scriber number 123450 to the device ‘subscriber line 37’ of type LI2, and
connects subscriber number 123451 to ‘subscriber line 38’ of the same type.

156

Input and Output Statements

Note that the ampersand (&, which means “and”) separates multiple parameter
values, with the effect that the command affects each parameter value speciﬁed.

SULII:DEV=LI2-37,SNB=123450&&123461.

Using a double ampersand (&&, which means “up to”) ensures that the command
affects all parameter values between the ﬁrst and the second value speciﬁed. This
example would initialise twelve (!) new subscriber lines.

Note that command names usually end on one of the letters I, E, C, S, or P. As in
, I indicates that some object will be initialised or created. P marks a printout
command. C and S indicate that some item will be changed (C) or set (S). Finally,
commands ending on E erase or end some item.

Receiving a Command

Entering a command on an I/O device, the I/O system receives the command and
“asks” the various SW units whether any of them owns the command. This avoids
the need for tables in the I/O system listing all commands and their receiving SW
units. If a program introduces new commands, it is not necessary to change any
tables in the I/O system.

Each command is received by one SW unit only. There is one command receiving
statement for each command. A command receiving statement is comparable to a
signal reception statement, in other words it speciﬁes where in the program the
program execution starts when receiving the command.

When the I/O system receives a command, the following things happen:

The I/O system seizes the I/O device from which the command was given
and assigns a free line and analysis buffer.

The I/O system analyses the syntax of the command.

The I/O system inserts the command parameters in the assigned analysis
buffer.

The I/O system searches for the SW unit and the program statement receiv
ing the command.

When the command receiving statement is found, the program execution
starts from this statement.

This is the syntax for the command receiving statement.

157

Plex-C 1

COMMAND

command name

TYPE

io-individual

command name = a global string symbol specifying the command name. The
maximum command name length is 7 characters.

= a global number symbol (coca number) specifying the

handle the command.

io-individual

, DEVICE IS

, SOURCE IS

;

command category

, ID IS

command category
command category. The I/O system uses the coca number to determine how to

= a ﬁeld variable (16 bits) which, after execution of the command

receiving statement, contains the number of the analysis buffer and the line
buffer the I/O system has seized.

io-device = a string variable (7 characters) which, after execution of the com
mand receiving statement, contains the name of the I/O device or an identiﬁer for
the sender if the command was given via a data channel. The name of the
io-device must be used if a new seizure is required later.

source = a ﬁeld variable (16 bits) which, after execution of the command receiv
ing statement, contains the address to the data channel. If the value of the source
is zero, the command was not given via a data channel. When the value is not
zero, the variable io-device contains an identiﬁer for the sender. The values of an
io-device and source must be used if a new seizure is to be made later.

io-device

source

Figure 8.6

Syntax for Command Receiving Statement

Note that older I/O statements may use an additional LINENUM IS lines part
(see Plex-C Language Description). This is not included in this book, do not use
this keyword in new software.

The command receiving statement translates into several assembly instructions.
The assembly code generated by one command receiving statement consists of
both signal sending and signal reception statements. Accordingly, executing a
command receiving statement involves several signals sent between different
function blocks. This implies that all pointers and temporary variables lose their
values!

Example 65

This example shows how to use a command receiving statement.

158

Input and Output Statements

DOCUMENT SUDAUPROGRAM;

....

PROGRAM; PLEX;

....

COMMAND SULII TYPE COCA307,

ID IS TIOID,

DEVICE IS CDEVTEMP,

SOURCE IS TSOURCE;

Figure 8.7

Command Receiving Statement

The ﬁrst word, COMMAND, indicates that this is a command receiving state
ment. The command name is SULII. If the operator enters command SULII on
any I/O terminal, the I/O system searches until it ﬁnds the corresponding com
mand receiving statement.

COCA307 is a 16 bits global number symbol in the receiving user block. Each bit
in it has a speciﬁc meaning. Bits 0-7, for example, include an authorization check
of the I/O device, to see if the command may be given from that particular I/O
terminal. Some I/O terminals belong to an administration centre which only
allows a limited set of commands that are relevant to the operation.

During the execution of the command receiving statement, the I/O system checks
each bit in the command category and reacts accordingly. The value of the sym
bol is determined earlier during the design ﬂow, and can be found in the Com
mand Description document. For more details, please see the course Plex-C 2.

The temporary variable TIOID contains, after reception of the command, the
number of the seized I/O record, i.e., the number of a pair of one analysis and one
line buffer, which are now linked to the I/O device sending the command. Later in
the Plex program, this variable addresses the seized analysis or line buffer. Please
note that the seized analysis and line buffers share the same number.

If the user program has to release the device, and perhaps later make an answer
printout on the same device, the name of the I/O device has to be stored. In this
example, the I/O system assigns the name of the I/O device to string variable
CDEVTEMP.

The variable TSOURCE speciﬁes if a command is received from an I/O device
directly connected to the exchange, or from an I/O device connected via a data
channel. If the parameter is omitted, the command could not be given from a
remote location, such as an operation and maintenance centre (OMC).

159

Plex-C 1

Command Rejection Statement

A command rejection statement rejects a command, if the same command was
given by the same or another exchange technician before and the user block is
still busy handling the old command. The Plex program rejects any second
attempt to process the same command, otherwise the second job would overwrite
variables in the data store already set by the ﬁrst job.

While a command is being processed, it is marked busy. The BUSY statement
rejects additional attempts to process a busy command, and prints out the follow
ing text on the I/O device issuing the rejected command.

NOT ACCEPTED

FUNCTION BUSY

Then the I/O system releases the I/O device.

BUSY, ID IS

io-individual

;

io-individual = a ﬁeld variable (16 bits) which contains the number of the seized
analysis buffer and the line buffer. The value was assigned to the variable in the
COMMAND statement.

Figure 8.8

Syntax for Command Rejection Statement

The command receiving statement assigns the variable io-individual the number
of the seized analysis/line buffer. In the command rejection statement, this
number is an input parameter and disconnects the I/O device from the seized
analysis/line buffer.

Example 66

This important example illustrates how to reject a command and when to save the
I/O parameters as permanent variables.

Observe the declarations of the variables and symbols, too.

160

Input and Output Statements

DECLARE;

! COMMAND CATEGORY NUMBER, SEE PARAM. LIST!

GLOBAL NSYMB COCA307 (#FFFF);

! COMMAND NAME, SEE PARAMETER LIST !

GLOBAL STRING SULII (7);

! STATE OF THE COMMAND HANDLING PROGRAM !

SYMBOL VARIABLE CCOMMANDSTATE = (IDLE, BUSY) DS;

! NUMBER OF THE ANALYSIS/LINE BUFFER PAIR !

VARIABLE CIOID 16 DS;

! DATA LINK !

VARIABLE CSOURCE 16 DS;

! NAME OF THE I/O DEVICE !

STRING VARIABLE CDEV 7 DS;

! TEMPORARY NAME OF THE I/O DEVICE !

STRING VARIABLE CDEVTEMP 7 DS;

! TEMPORARY NUMBER OF THE I/O BUFFERS !

VARIABLE TIOID;

! TEMPORARY DATA LINK !

VARIABLE TSOURCE;

END DECLARE;

PROGRAM; PLEX;

....

COMMAND SULII TYPE COCA307,

ID IS TIOID,

DEVICE IS CDEVTEMP,

SOURCE IS TSOURCE;

IF CCOMMANDSTATE /= IDLE THEN

BUSY, ID IS TIOID;

EXIT;

FI;

CCOMMANDSTATE = BUSY;

CIOID = TIOID;

CDEV = CDEVTEMP;

CSOURCE = TSOURCE;

....

CCOMMANDSTATE = IDLE;

Figure 8.9

Command Rejection

161

Plex-C 1

The command SULII (subscriber line initiate) is received with the COMMAND
statement. The command connects subscriber numbers to subscriber line devices.
The temporary variable TIOID contains the number of the seized line/analysis
buffer.

The variable CCOMMANDSTATE determines whether the command is already
in progress (BUSY) or not (IDLE). The IF statement checks whether the com
mand is busy, i.e., whether someone else is using the command. If the command
is busy, the BUSY statement rejects the command and releases the seized I/O
device. The EXIT statement returns control to the operating system.

If the command is idle, the program continues and sets the command state to busy
so that nobody else can use the command.

Then, the program stores the temporary values of the I/O parameters as DS varia
bles. If the program stored these parameters directly as DS variables, any new
attempt to issue the command would overwrite the original values. Also note that
the I/O device name is a string parameter and cannot be stored in a temporary
variable. Hence the device name is stored in CDEVTEMP ﬁrst, and later saved in
CDEV.

Finally, after executing all statements belonging to the command, the program
sets the command state to idle, allowing others to use the command again.

Seizure of an I/O Device

When the I/O system receives a command, the I/O system seizes the I/O device,
assigns a free analysis/line buffer, and inserts the command parameters in the
analysis buffer. The situation is different when a user block has to make a printout
by itself, for example, an error printout. Then the user block must be able to seize
the I/O device. There are two ways of doing this. The user block can either
directly tell the I/O system which I/O device to seize, or it can order seizure of an
I/O device with a speciﬁc function, for example, a device for alarm or error print
outs. The I/O system then selects the I/O device associated with this type of func
tion and seizes it.

If the device is busy, the user block queues the seize request in an I/O device
buffer.

The SEIZE statement applies to alphanumeric I/O devices only. SEIZE reserves
the selected device and a free analysis/line buffer.

162

Input and Output Statements

SEIZE DEVICE

io-individual

label

io-code
contains an answer code from the I/O system.

pointer

, CODE IS

io-code

, SOURCE IS

;

OR STANDBY

, ID IS

io-individual

ABRANCH IS

label

, POINTER IS

pointer

io-device

io-device = string variable or string symbol which contains the name of the I/O
device to be seized.

= a ﬁeld variable (16-bits) which, after execution of the statement,

contains the number of the seized analysis and line buffer.

= program label to which a jump is made if seizure fails.

= a structured 16 bits variable which, after execution of the statement,

= any pointer in the program to be saved. Pointer values and temporary

variables are destroyed when the SEIZE statement is executed.

source = a 16 bit ﬁeld variable which, before the execution of the statement, con
tains zero or a data channel address. The variable is assigned its value in a previ
ously executed COMMAND statement. If the value is not zero, the data channel
from which the command was given is seized.

source

Figure 8.10

Syntax for Seizure

The SEIZE statement returns an answer state (io-code) to the user block. This
answer code contains information about the seizure. For example, if the seizure
did not succeed, the answer code contains information about the reason.

Most I/O statements return an io-code, not only SEIZE DEVICE. Each bit in the
io-code variable has a certain signiﬁcance. Some bits have a common signiﬁ
cance for all I/O statements, while others indicate different problems for different
statements.

If an I/O statement fails, the Plex program should test the various bits in the
io-code variable and ﬁnd out where the trouble is.

There are design rules showing the answer codes for different I/O statements. The
Plex-C Language Description contains a full list of all io-codes. The SEIZE
DEVICE statement sets one of the following bits to one, if SEIZE fails. Other
wise all bits are reset to zero.

I/O device fault

the seizure queue is ﬁlled

the I/O device is not connected

unknown seize code

163

Plex-C 1

The Plex program usually jumps to the ABRANCH label, if the SEIZE statement
fails. See Chapter 16.4 in the Plex-C Language Description for details. If the pro
gram jumps to the ABRANCH label, the device is not seized. The io-code does
not show whether or not the I/O system seized a stand-by device.

Normally, all pointers and temporary variables lose their values in I/O statements
since they involve signalling. The POINTER IS keyword, however, allows to save
one pointer variable. This I/O statement saves and returns the pointer variable
without changes. Store all other pointers and temporary variables as DS varia
bles, if needed after the I/O statement.

Example 67

This example shows the seize statement.

PROGRAM; PLEX;

....

SEIZE DEVICE CDEV OR STANDBY,

ID IS CIOID,

ABRANCH IS IOERROR420,

CODE IS CIOCODE,

POINTER IS DEVP;

SOURCE IS CSOURCE;

Figure 8.11

Seizure of Device

The string variable CDEV contains the name of the device to be seized. If the sei
zure succeeds, the number of the assigned analysis/line buffer appears in the ﬁeld
variable CIOID after completion of the statement. The variable CSOURCE con
tains the number of a remote data channel if any.

The program jumps to label IOERROR420, if anything unexpected occurs in the
statement, for instance, the device is blocked. The I/O system stores the answer
code or io-code in variable CIOCODE, which is a 16 bit structured variable.

If the device CDEV is out of order at the time of seizure, or if it cannot be seized
because of some other reason, OR STANDBY indicates to seize a stand-by
device instead.

The seize statement saves the value of pointer variable DEVP.

Function Seizure

If the program needs to seize one or more I/O devices linked to a speciﬁc func
tion, e.g., an alarm printer, use the statement for function seizure of an I/O device.

164

Input and Output Statements

SEIZE DEVICE FOR

function code

function code = local or global number symbol that deﬁnes the function code or

, CODE IS

io-code

;

, ID IS

io-individual ,

ABRANCH IS

label

, POINTER IS

pointer

a variable that contains the function code.

Figure 8.12

Syntax for Function Seizure

The other parts of this statement, ID IS ..., ABRANCH IS... etc., have the same
function as in the other seize statement.

The function code is a printout category and speciﬁes the type of printout. The
code directs the printout to function-dedicated I/O devices.

Release of an I/O Device

Plex programs release all seized devices, when the communication between the
user block and I/O device ends, making the I/O device available to other tasks.

The I/O system releases devices, if the processing of a command requires too
much time. It is not acceptable to block the I/O device for a relatively long time.
Instead, Plex programs release the I/O terminal making it available to other tasks
in the meantime. Later, the Plex program may seize the I/O device again, if the
command requires an answer printout on that I/O device.

It is not necessary to release a device, if the program rejected a command with a
BUSY statement. This statement automatically releases the I/O device.

RELEASE DEVICE

io-individual =

, CODE IS

io-code

;

io-individual ,

ABRANCH IS

label

, POINTER IS

pointer

a 16 bit ﬁeld variable containing the number of the seized analy-

sis/line buffer associated with the I/O device. Note that it is not necessary to
specify the name of the I/O device itself.

For all other items, see the SEIZE DEVICE statement.

, ID IS

Figure 8.13

Syntax for Release

165

Plex-C 1

Example 68

This example shows how to release the analysis buffer and the line buffer.

PROGRAM; PLEX;

....

RELEASE DEVICE, ID IS CIOID,

ABRANCH IS IOERROR420,

CODE IS CIOCODE,

POINTER IS CALLDATAP;

Figure 8.14

Release of I/O Device

There is no need to indicate the name of the device. The I/O system knows which
I/O device is connected to the line/analysis buffer and releases that device. In this
example, the variable CIOID stores the number of the analysis/line buffer.

Preliminary Overview

Here is an intermediate overview of the I/O statements. I/O statements can be
alphanumeric or ﬁle-oriented statements. COMMAND is an input statement used
for command receiving. BUSY is an input statement to reject a command, if the
command is given several times simultaneously.

I/O devices need to be locked or seized before they can be used. There are two
locking statements, SEIZE DEVICE and SEIZE DEVICE FOR, but only one
unlocking statement, RELEASE DEVICE.

Input Output

Statements

Alphanumeric I/O

File-oriented I/O

Input

Output

Locking

COMMAND

SEIZE DEVICE

BUSY

SEIZE DEVICE FOR

RELEASE DEVICE

Figure 8.15

Overview of main I/O statements

166

Input and Output Statements

Fetching Information from an Analysis Buffer

The COMMAND statement does not transfer the command parameters to the
user block. It merely informs the program that the I/O system has received a com
mand and that the command parameters command exist in an analysis buffer. To
fetch these parameters from the analysis buffer, use one of the two fetch state
ments:

•

FETCH PARAMETER

•

FETCH

The FETCH PARAMETER statement transfers command parameters into the
program. The FETCH statement transfers all other input texts into the program.

Read

I/O System

User

Analysis Buffer
144 Characters

Line Buffer
72 Characters

Program Store

Fetch

Insert

Write

Block

Figure 8.16

Fetching parameters from an analysis buffer

167

Plex-C 1

FETCH

the parameters to be fetched (maximum 15 characters).

value

after

io-individual

ment, and is an input parameter to this statement.

label
the parameters.

io-code

after

contains an answer code from the I/O system.

pointer

PARAMETER

value

NUM
STRING
ID
IDFCTR
NUMSTRING

1..

io-individual

, ABRANCH IS

label

;

, POINTER IS

pointer

, CODE IS

io-code

parameter name = explicit string, string symbol or a string variable that deﬁnes

= ﬁeld variable or string variable which,

execution of the statement,

contains the parameter value.

= a 16 bit ﬁeld variable containing the number of the seized analy-

sis/line buffer. This variable was set in an earlier COMMAND or SEIZE state

= program label to which a jump is made if something fails when fetching

= a structured 16 bit variable which,

execution of the statement,

= any user block pointer to be saved. Pointer and temporary variables are

destroyed when the FETCH PARAMETER statement is executed.

parameter name

, ID IS

Figure 8.17

Syntax for Fetching Parameters

In the FETCH PARAMETER statement, specify the expected data type. There
are ﬁve possible data types:

NUM

indicates a numeric value. Usually values between 0 and 65535
are permitted, unless the variable has been declared as R. In that
case, the maximum value depends on the processor in the
exchange.

STRING

Indicates a text string.

Indicates an identiﬁer. An identiﬁer is, for example, part of a
device name (such as ‘LI2’ in the device name ‘LI2-42’). The
name consists of a letter followed by letters and/or digits. Use
FETCH PARAMETER . . . NUM to fetch the device number
‘42’ in the example.

IDFCTR

Indicates an identiﬁer. In addition to the syntax of the ID identi
ﬁer, the special characters #, + and % may be used as well.

168

Input and Output Statements

NUMSTRING

Indicates a numeric string, e.g. a telephone number. The reason
why it is fetched as a string, and not a ﬁeld variable, is that the
numeric value is larger than 65 535.

CODE IS... and POINTER is... work as in a SEIZE statement.

Example 69

This example shows how to fetch the parameters for the command SULII. Con
sider this example:

S U L I I : D E V = L I 2 — 5 3 1 , S N B = 3 2 1 0 2 0 ;

SULII is an abbreviation for subscriber line initiate and its parameter block con
sists of two parameters: DEV = LI2–531 and SNB = 321020. The command links
the subscriber number 321020 to the LI2 device number 531.

When the I/O system receives the command, it stores the parameters in a free
analysis buffer and sends a signal to the user block with the number of the seized
buffer. The Plex statement COMMAND receives this signal.

I/O System

DEV=LI2-531, SNB=321020;

Fetch

User Block

Analysis Buffer

Parameter

Figure 8.18

Parameters for command SULII in the analysis buffer

Figure 8.18 shows the contents of the analysis buffer after the I/O system
received the command. In the user block, the program fetches each parameter
separately. This is the code for fetching parameter DEV:

169

Plex-C 1

PROGRAM; PLEX;

....

FETCH PARAMETER DEV

ID TO CDEVNAME,

NUM TO TDEVNO,

ID IS CIOID,

ABRANCH IS IOERROR420,

CODE IS CIOCODE,

POINTER IS COMMANDPTR;

Figure 8.19

Fetching Parameter DEV

This statement fetches parameter DEV. DEV is a global string symbol, receiving
the value “DEV” in the parameter list. The statement fetches the identiﬁer or
device name LI2 with ID TO and stores it in the string variable CDEVNAME.
The statement fetches the number of the device, 531, with NUM and stores it in
variable TDEVNO.

Figure 8.20 shows the contents of the variables CDEVNAME and TDEVNO
after execution of the statement.

Data Store

CDEVNAME

LI2

Register Memory

DR3 (TDEVNO)

531

Figure 8.20

Contents of DS variable CDEVNAME and temporary variable TDEVNO

The variable CIOID contains the number of the seized analysis/line buffer. The
COMMAND statement sets this parameter when receiving command SULII.

Depending on the type of error, the program execution continues from the label
IOERROR420. See Chapter 16.4 in the Plex-C language description for details.

The variable CIOCODE contains the answer code from the system and the
pointer value will be saved in the pointer COMMANDPTR.

170

Input and Output Statements

The FETCH PARAMETER statement fetches one parameter value only. There
fore, a new FETCH PARAMETER statement fetches the second parameter in
Example 69 (SNB=321020).

PROGRAM; PLEX;

....

FETCH PARAMETER SNB

NUMSTRING TO CSUBNO,

ID IS CIOID,

ABRANCH IS IOERROR430,

POINTER IS COMMANDPTR;

Figure 8.21

Fetching Parameter SNB

The statement fetches the value 321020 and stores it in the string variable
CSUBNO. Because the subscriber number contains six digits, it is too large for
ordinary ﬁeld variables. Therefore, the program uses a numeric string.

Note that this statement does not receive the io-code; it is an optional parameter,
and it may not always be necessary to check the reason for the unexpected behav
iour of an I/O statement.

Example 70

This example explains the program handling command DULSI and its parame
ters. It provides a useful overview of how the I/O statements handle commands.

The command DULSI has the following syntax:

D U L S I : R = 1 0 , T D M = 1 5 ;

See page 173 for the command reception program and page 172 for the corre
sponding declare sector.

The program receives the command DULSI (disturbance level statistics initiate)
with the statement COMMAND. After execution of the command receiving
statement, the number of the seized analysis/line buffer is in the variable TIOID,
and the name of the device in the string variable CDEVTEMP. The number of the
data link is stored in the variable TSOURCE.

The IF statement investigates whether the command is already in progress. If not
(CCOMSTATE = IDLE), the program continues and sets variable CCOMSTATE
to busy. Then, the program saves the analysis/line buffers number, the data link
number and the I/O device name in DS variables CIOID, CSOURCE and CDEV.

171

Plex-C 1

DOCUMENT ABCDEUPROGRAM;

DECLARE;

! GLOBAL SYMBOLS !

GLOBAL NSYMB COCA001 (#FFFF);

GLOBAL STRING DULSI (7);

GLOBAL STRING R (7);

GLOBAL STRING TDM (7);

! COMMON VARIABLES !

SYMBOL VARIABLE CCOMSTATE = (IDLE, BUSY) DS;

VARIABLE CIOID 16 DS;

VARIABLE CSOURCE 16 DS;

VARIABLE CROUTE 16 DS;

VARIABLE CRESULT 16 DS;

VARIABLE CTIME 16 DS;

STRING VARIABLE CDEV 7 DS;

STRING VARIABLE CDEVTEMP 7 DS;

! TEMPORARY VARIABLES !

VARIABLE TIOID;

VARIABLE TSOURCE;

END DECLARE;

Figure 8.22

Declare Sector for Example 70

172

Input and Output Statements

PROGRAM; PLEX;

....

COMMAND DULSI TYPE COCA001,

ID IS TIOID,

DEVICE IS CDEVTEMP,

SOURCE IS TSOURCE;

IF CCOMSTATE /= IDLE THEN

BUSY, ID IS TIOID;

EXIT;

FI;

CCOMSTATE = BUSY; ! COMMAND ACCEPTED !

CIOID = TIOID;

CDEV = CDEVTEMP;

CSOURCE = TSOURCE;

FETCH PARAMETER R

NUM TO CROUTE,

ID IS CIOID,

ABRANCH IS RELEASE610;

FETCH PARAMETER TDM

NUM TO CTIME,

ID IS CIOID,

ABRANCH IS RELEASE610;

....

SEND SIGMA WITH CROUTE,CTIME;

EXIT;

! ACTION IN BLOCK RECEIVING SIGNAL SIGMA,

EG. PROCESSING OF CROUTE AND CTIME DATA !

ENTER SIGMAR WITH CRESULT;

! GENERATE PRINTOUT IF NECESSARY !

....

RELEASE610)

RELEASE DEVICE,

ID IS CIOID,

ABRANCH IS EXIT620;

EXIT620)

CCOMSTATE = IDLE;

EXIT;

Figure 8.23

Receiving a Command with Parameters

The program fetches the parameters from the analysis buffer using two FETCH
PARAMETER statements. The program sends the parameter values to some
cooperating block with the signal SIGMA. That block processes the data. It
might also return some result information with the return signal SIGMAR, and
the user block might generate a result printout, see page 179. Then the program

173

Plex-C 1

releases he I/O device and resets CCOMSTATE to IDLE. If any problems occur
during the parameter fetch, the program jumps to the ABRANCH label
RELEASE610. At this label, the program releases the device and marks the com
mand program free with CCOMSTATE = IDLE.

It is important that the program always releases the I/O device (with RELEASE
DEVICE) and the user block (with CCOMSTATE = IDLE) at the end of any I/O
communication.

Observation

Please note that it is not possible to fetch a parameter value twice with the
FETCH PARAMETER statement, since this statement removes the value from
the analysis buffer. Therefore, programs store fetched parameters as DS variables
if needed later in the program.

Check

Some commands, for instance, PCORI in older APZ versions, can carry several
parameter blocks. A FETCH PARAMETER statement affects only one parameter
block in the command. Bit E in the answer code (io-code) is equal to one, if there
are more parameter blocks in the analysis buffer. To access the next parameter
block in the user block, use a CHECK statement.

CHECK ,

io-individual

, ABRANCH IS

label

, CODE IS

io-code

;

, POINTER IS

pointer

ID IS

Figure 8.24

Syntax for CHECK

Example 71

This example checks whether the seized analysis buffer contains additional
parameter blocks apart from those fetched.

PROGRAM; PLEX;

....

CHECK, ID IS CIOID,

ABRANCH IS NOMOREBLOCKS420,

CODE IS CIOCODE,

POINTER IS DEVDATAP;

Figure 8.25

Checking for More Parameter Blocks

174

Input and Output Statements

Variable CIOID contains the number of the seized analysis buffer.

If any parameter blocks remain in the analysis buffer, the analysis buffer pointer
is set to the ﬁrst one of them, which could now be fetched with a FETCH
PARAMETER statement. If the buffer is empty, the program execution continues
from the ABRANCH label NOMOREBLOCKS420. After execution, the variable
CIOCODE contains the answer code from the I/O system.

Fetch

While user programs use the statement FETCH PARAMETER to fetch parameter
values from the analysis buffer, the FETCH statement receives any other non-
parameter input.

FETCH

ID IS

io-individual

, CODE IS

io-code

ABRANCH IS

label

, POINTER IS

pointer

BUFFER TO

CHAR TO

ELEMENT TO

ID TO

STRING TO

NUM TO

SPEC TO

variable 1

variable 2

string variable 1

string variable 2

string variable 3

variable 3

variable 4

, CHANUM IS

variable 6

;

, TYPE IS

variable 5

buffer variable

Figure 8.26

Syntax for FETCH

FETCH BUFFER TO .... fetches the complete contents of the analysis buffer to a
buffer variable. Variable 6 contains the total number of characters in the buffer
variable after execution of the statement.

FETCH CHAR TO .... reads one character from the analysis buffer to variable 1.

Use FETCH ELEMENT TO .... if the type of the element to be fetched from the
analysis buffer is not known. If the fetched element is a numeral or special char
acter, it is fetched to variable 2; and if it is s a text string, it is fetched to string
variable 1. After execution of the statement, variable 5 contains the type of ele
ment fetched. Use the TYPE IS variable 5 section only in combination with
FETCH ELEMENT TO....

175

Plex-C 1

Possible values for variable 5 are:

Numeral

Special character

Identiﬁer

Text string

No element in buffer

FETCH ID TO .... fetches an identiﬁer from the analysis buffer to string
variable 2.

FETCH STRING TO .... fetches a string from the analysis buffer to string varia
ble 3.

FETCH NUM TO .... fetches a numeral from the analysis buffer to variable 3
which is a ﬁeld variable of not more than 16 bits, or an R variable.

FETCH SPEC TO .... fetches a special character from the analysis buffer to vari
able 4.

Note that FETCH receives single and special characters in regular ﬁeld variables.

Example 72

This example shows how to fetch the contents of the analysis buffer. Assume the
following contents in the analysis buffer:

NUMBER=15;

Fetch the parameter using the following statements; variable CIOID contains the
number of the seized analysis buffer.

176

Input and Output Statements

PROGRAM; PLEX;

....

FETCH STRING TO CSTRINGVAR,

ID IS CIOID,

ABRANCH IS FETCHERR300;

FETCH SPEC TO CSPCHAR,

ID IS CIOID,

ABRANCH IS FETCHERR300;

FETCH NUM TO CNUMVAR,

ID IS CIOID,

ABRANCH IS FETCHERR300;

FETCH ELEMENT TO CSPEC OR CTEXT,

ID IS CIOID,

ABRANCH IS FETCHERR300,

TYPE IS CCHARTYPE;

Figure 8.27

Fetching Strings from the Analysis Buffer

Figure 8.28 illustrates how the various FETCH statements assign values to the
different variables.

Data Store

FETCH STRING...

FETCH NUM...

NUMBER=15;

NUMBER

CSPCHAR

CSPEC

Program Store

FETCH SPEC...

FETCH ELEMENT... TYPE IS

Analysis Buffer

CNUMVAR

CCHARTYPE

CSTRINGVAR

Figure 8.28

Fetching data from the analysis buffer

177

Plex-C 1

Figure 8.28 shows that variable CSTRINGVAR stores the text string
‘NUMBER’, variable CSPCHAR stores the special character ‘=’, and variable
CNUMVAR stores 15.

The FETCH ELEMENT.... statement stores the semicolon in variable CSPEC
and the value 1 in variable CCHARTYPE, indicating that the statement found a
special character.

Find

Searching for an optional text string in the analysis buffer, use the FIND state
ment.

string.

FIND

io-individual

, ABRANCH IS

label

, CODE IS

io-code

;

, POINTER IS

pointer

text = an explicit string, string symbol or string variable that deﬁnes the searched

text

ID IS

Figure 8.29

Syntax for FIND

FIND searches for a speciﬁed text string in the analysis buffer, for example, an
identiﬁer, and sets the analysis buffer pointer to the ﬁrst character after the found
string. If the string is not found, the execution jumps to the ABRANCH label.

Example 73

Suppose that the analysis buffer contains this string:

DEV = KR3;

PROGRAM; PLEX;

....

FIND "DEV", ID IS CIOID,

ABRANCH IS FINDERR400,

CODE IS CIOCODE;

Figure 8.30

Finding a Parameter

After the statement, FIND sets the analysis buffer pointer on the character ’=’. To
fetch the speciﬁed string, use the FETCH ... statement.

178

Input and Output Statements

Output of Information

To generate a printout, use the INSERT statement. INSERT transfers printable
data from the user program to the line buffer (see Figure 8.31). After inserting all
text for one line into the line buffer, the user block orders the I/O system to print
out the contents of the line buffer on the I/O device with the WRITE statement.

Read

I/O System

User

Analysis Buffer

144 Characters

Line Buffer

72 Characters

Program Store

Fetch

Insert

Write

Block

Figure 8.31

Inserting data in the line buffer

179

Plex-C 1

INSERT

string

number

position

io-individual

MAND or SEIZE statement.

pointer

num

STRING

string

TEXT

TAB

position

io-individual

;

, POINTER IS

pointer

HEX

VALUE

number

, FORMAT IS

num

= string variable, global or local string symbol containing a string to be

inserted in the line buffer (maximum 45 characters). String can also be an
explicit string.

textcode = local number symbol that deﬁnes a standard text.

= a 16 bit or R ﬁeld variable containing a hexadecimal or decimal num

ber to be inserted in the line buffer.

= numeral or ﬁeld variable indicating where the next character is to be

placed in the line buffer.

= a 16 bit ﬁeld variable containing the number of the seized analy-

sis/line buffer. This variable has been assigned the number in an earlier COM

= any pointer in the program to be saved. Pointers and temporary vari

ables are destroyed when the INSERT statement is executed

= numeral indicating the maximum number of digits in the line buffer for a

numeric variable that is inserted using INSERT VALUE.

textcode

, ID IS

Figure 8.32

Syntax for INSERT

Note that the FORMAT IS ... section is mandatory when inserting a numeric
value with INSERT VALUE.

Do not insert strings longer than 45 characters. The reason is that the INSERT
STRING statement sends the string with some signal. Signals can carry only 25
data words and two data words are needed here for other purposes. Hence, 23
data words are available for the text string, which is equivalent to 45 characters (1
character needs 8 bits or a half-word, and the ﬁrst half-word contains the length
of the string).

Example 74

This example inserts the content of string variable CSTATE in the line buffer.
Variable CBET stores the number of the line buffer, which received its value in an
earlier COMMAND or SEIZE statement.

180

Input and Output Statements

The INSERT statement also saves the value of pointer ROUTEP.

PROGRAM; PLEX;

....

CSTATE = "BUSY";

INSERT STRING CSTATE, ID IS CBET,

POINTER IS ROUTEP;

Figure 8.33

Inserting a String

Figure 8.34 shows the contents of the line buffer after execution of the statement,
if the string variable CSTATE has the value “BUSY”.

Line Buffer

BUSY

Figure 8.34

Insertion of a string variable into a line buffer

181

Plex-C 1

Example 75

This example inserts two global string symbols in a line buffer.

DECLARE;

....

GLOBAL STRING T (15);

GLOBAL STRING S (15);

....

END DECLARE;

PROGRAM; PLEX;

....

INSERT STRING S, ID IS CBET;

INSERT STRING T, ID IS CBET;

....

END PROGRAM;

Figure 8.35

Inserting two strings in a line buffer

Suppose that the string T received the value GOODBYE, and S the value HELLO
in the parameter list. Figure 8.36 shows the contents of the line buffer in this case
after execution of the statements above.

Line Buffer

HELLOGOODBYE

Figure 8.36

Contents of the line buffer after both INSERT STRING statements

INSERT TEXT puts standard texts in the line buffer. These texts are stored in the
I/O system, and they are available for common printouts in all SW units. The fol
lowing list shows some of the existing standard texts (English version). Accord
ing to design rules, declare the texts as local number symbols in the user blocks
using these symbol names and values.

182

Input and Output Statements

Number Symbol Value

Text (English version)

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

Figure 8.37

Number symbols for standard texts

183

Plex-C 1

Insert Text Detal

The statement INSERT TEXT DETAL puts the most recently fetched command
parameter argument in the line buffer. Suppose the operator entered a faulty or
inappropriate command parameter value. In this case, the I/O program usually
prints the text UNREASONABLE VALUE followed by a repetition of the param
eter. In command description documents, the keyword details indicates that
INSERT TEXT DETAL should be used.

Example 76

A program needs to make the following error printout.

NOT ACCEPTED

UNREASONABLE VALUE

DEV=BT3-42;

Figure 8.38

Sample error printout

These are the corresponding declarations and insertion statements.

DECLARE;

....

NSYMB DETAL = 0;

! PRINTOUT DETAILS

NSYMB NOACC = 3;

! PRINTOUT NOT ACCEPTED

NSYMB UNRVA = 10; ! PRINTOUT UNREASONABLE VALUE

....

END DECLARE;

PROGRAM; PLEX;

....

INSERT TEXT NOACC,ID IS CID;

....

INSERT TEXT UNRVA, ID IS CID;

....

INSERT TEXT DETAL, ID IS CID;

....

END PROGRAM;

Figure 8.39

Inserting an error message

184

Input and Output Statements

Insert Tab

INSERT TAB structures the printout. The statement sets the line buffer pointer to
the position where to insert the next character in the line buffer. The numbering in
the line buffer starts from position 1.

Specify the pointer value as a numeral, variable, or number symbol. With TAB,
the pointer moves from one position to another, forwards or backwards. TAB
does not change the characters between the two positions.

Example 77

DECLARE;

....

GLOBAL STRING ERR (15);

....

VARIABLE CIOID 16 DS;

....

END DECLARE;

PROGRAM; PLEX;

....

INSERT TAB 5,

ID IS CIOID;

INSERT STRING ERR,

ID IS CIOID;

Figure 8.40

Setting the Tabulator

INSERT TAB 5 sets the line buffer pointer to position 5.

The next statement inserts the value of the global string symbol ERR, which has
the value “ERROR” in the parameter list. The word ERROR starts at position 5.
Figure 8.41 shows the contents of the line buffer after execution of the two state
ments. The line buffer pointer is now at position 10.

Line Buffer

E R R O R

Figure 8.41

Inserting string symbol ERR at position 5

185

Plex-C 1

Insert Value

The following examples show the contents of the line buffer for different
INSERT VALUE statements. Assume that the line buffer pointer is set to position
1 before each statement.

Example 78

PROGRAM; PLEX;

....

CGAMMA = 14;

INSERT VALUE CGAMMA, ID IS CIOID,

FORMAT IS 5;

Figure 8.42

Format is 5

FORMAT IS 5 reserves ﬁve positions for the value of CGAMMA in the line
buffer and sets the buffer pointer to position 6 in the line buffer.

Figure 8.43 shows the contents of the line buffer after execution of the statement
above.

Line Buffer

Figure 8.43

Contents of the line buffer after FORMAT IS 5

186

Input and Output Statements

Format is 5R/5Z

PROGRAM; PLEX;

....

CGAMMA = 14;

CDELTA = 15;

INSERT VALUE CGAMMA, ID IS CIOID,

FORMAT IS 5R;

INSERT VALUE CDELTA, ID IS CIOID2,

FORMAT IS 5Z;

Figure 8.44

Format is 5R/5Z

FORMAT IS 5R inserts CGAMMA's value into the line buffer, reserving 5 digits
and aligned right (R), and ﬁlls any remaining positions with leading blanks.

FORMAT IS 5Z inserts CDELTA’s value into the line buffer, reserving 5 digits
and aligned right, and ﬁlls any remaining positions with leading zeroes (Z).

Figure 8.45 shows the contents of the line buffers and after execution of the state
ments above. In both cases, the line buffer pointer is set to 6 afterwards.

Line Buffer CIOID (value of CGAMMA)

Line Buffer CIOID2 (value of CDELTA)

Figure 8.45

Contents of the line buffers after FORMAT IS 5R and FORMAT IS 5Z

187

Plex-C 1

Format = 5H

PROGRAM; PLEX;

....

CGAMMA = 14;

INSERT HEX VALUE CGAMMA, ID IS CIOID,

FORMAT IS 5H;

Figure 8.46

Format is 5H

INSERT HEX VALUE inserts the hexadecimal value of CGAMMA into the line
buffer. As the format is speciﬁed as 5H, the number is preceded by the characters
H’. Figure 8.47 shows the contents of the line buffer after execution of these
statements.

’

Line Buffer

Figure 8.47

Contents of the line buffer after FORMAT IS 5H

Format = 5RH/5ZH

PROGRAM; PLEX;

....

CGAMMA = 14;

CDELTA = 15;

INSERT HEX VALUE CGAMMA, ID IS CIOID,

FORMAT IS 5RH;

INSERT HEX VALUE CDELTA, ID IS CIOID2,

FORMAT IS 5ZH;

Figure 8.48

Format is 5RH/5ZH

FORMAT IS 5RH inserts the hexadecimal value for CGAMMA into the line
buffer. The value is aligned right and preceded by H’ and leading blanks. If the

188

Input and Output Statements

format speciﬁcation were FORMAT IS 5R instead, i.e., without an H, the line
buffer would only contain ‘E’.

FORMAT IS 5ZH inserts the hexadecimal value for CDELTA into the line buffer.
The value is aligned right and preceded by H’ and leading zeroes.

’

Line Buffer CIOID (value of CGAMMA)

Line Buffer CIOID2 (value of CDELTA)

Figure 8.49

Contents of the line buffers after FORMAT IS 5RH and FORMAT IS 5ZH

Writing on an I/O Device from Line Buffer

With the INSERT statements, the user block assembles output information in a
line buffer, without printing the information on any I/O device. The line buffer
prepares the printout, the information in a line buffer corresponds to one line in a
printout. The line buffer may contain up to 72 characters, which is also the maxi
mum length of any output string.

If a printout line is complete, programs send it to the I/O device with the WRITE
statement. Printing several lines, load the line buffer with INSERT, order a print
out of its content with WRITE, load the buffer again, order a new printout, and so
forth.

189

Plex-C 1

Read

I/O System

User

Analysis Buffer
144 Characters

Fetch

Insert

Write

Line Buffer
72 Characters

Program Store

Block

Figure 8.50

Writing the contents of a line buffer on an I/O device

Figure 8.50 illustrates the purpose of the WRITE statement, sending the contents
of the speciﬁed line buffer to the I/O device. The statement determines whether
the printout is followed by a form feed/change of page (WRITE BEFORE NEW
PAGE) or one or more line feeds (WRITE BEFORE 1 NL etc.).

If WRITE has no special indication, a line feed follows the printout; in other
words, WRITE, ID IS... and WRITE BEFORE 1 NL, ID IS ... are equivalent.

Use WRITE BEFORE 0 NL to avoid moving to a new line.

190

Input and Output Statements

number

io-individual

or SEIZE statement.

label

io-code

after

contains an answer code from the I/O system.

pointer

WRITE

AFTER

BEFORE

io-individual

, CODE IS

io-code

;

, ABRANCH IS

label

, POINTER IS

pointer

number

NEWPAGE

= numeral or ﬁeld variable indicating the number of new lines that

should follow (BEFORE) or precede (AFTER) the printout.

= a 16 bit ﬁeld variable containing the number of the seized analy-

sis/line buffer. This variable has been assigned a value in an earlier COMMAND

= program label to which a jump is made if something fails when writing

on the I/O device.

= a structured 16 bit variable which,

execution of the statement,

= any pointer in the program to be saved. Pointers and temporary vari

ables are destroyed when the WRITE statement is executed.

, ID IS

Figure 8.51

Syntax for WRITE

Example 79

Please read this example carefully: this Write statement, using BEFORE,

•

ﬁrst prints the text/buffer contents and

•

then starts a new page.

Any further printout appears on this new page.

PROGRAM; PLEX;

....

WRITE BEFORE NEWPAGE, ID IS CIOID,

ABRANCH IS ERROR300;

Figure 8.52

Writing Before New Page

191

Plex-C 1

Example 80

In this example, the form feed occurs before the printout; in other words, the
printout starts on a new page.

PROGRAM; PLEX;

....

WRITE AFTER NEWPAGE, ID IS CIOID,

ABRANCH IS ERROR300;

Figure 8.53

Writing After New Page

Example 81

This example inserts three line feeds before the printout. Note: the number of line
feeds could also be stated as a variable.

PROGRAM; PLEX;

....

WRITE AFTER 3 NL, ID IS CIOID,

ABRANCH IS ERROR300;

Figure 8.54

Writing After New Line

Example 82

This complete example shows the statements needed to perform the following
printout:

CONGESTION

....

H’0F

Figure 8.55

Printout on Screen

Note: the dots (....) indicate empty lines in the printout.

192

Input and Output Statements

DECLARE;

....

GLOBAL STRING CONGESTION (15);

VARIABLE CNR 8 DS;

VARIABLE CIOID DS;

....

END DECLARE;

PROGRAM; PLEX;

....

CNR = 15;

INSERT STRING CONGESTION, ID IS CIOID;

WRITE BEFORE 5 NL, ID IS CIOID,

ABRANCH IS IOERROR620;

INSERT HEX VALUE CNR, ID IS CIOID,

FORMAT IS 4 ZH;

WRITE, ID IS CIOID,

ABRANCH IS IOERROR 630;

Figure 8.56

Inserting and Writing

With INSERT STRING, the contents of the global string symbol CONGESTION
are inserted in the line buffer. Then the contents are written on the I/O device that
is currently assigned to this line buffer, followed by ﬁve line feeds.

With INSERT HEX VALUE, the hexadecimal value of the variable CNR is
inserted in the line buffer. The format of this printout consists of four characters
aligned right; the value is preceded by the characters H’ and leading zeroes.

Finally a printout of the number is ordered, with one line feed following. Lacking
other speciﬁcations, the default value WRITE BEFORE 1 NL applies.

Reading from an I/O Device to Analysis Buffer

The last alphanumeric I/O statement is the READ statement. It is only used for
dialogue commands such as TCTDI (test call via test device initiate). These com
mands include queries from the user block to the exchange technician. The tech
nician will then answer the queries with a certain text. Both parties participate in
a dialogue.

To enable the operator to answer such queries, programs need the READ state
ment transferring information from the I/O device (for example, a text string from
the technician) to the user program.

193

Plex-C 1

Read

I/O System

User

Analysis Buffer
144 Characters

Fetch

Insert

Write

Line Buffer
72 Characters

Program Store

Block

Figure 8.57

Reading from an I/O device to an analysis buffer

The READ statement transfers information from the I/O device to an analysis
buffer. To send the information from the analysis buffer to the user block, the
FETCH statement is used (discussed on page 175).

READ can transfer up to 144 characters, corresponding to two lines on the I/O
device.

io-individual

or SEIZE statement.

label

io-code

after

contains an answer code from the I/O system.

pointer

READ ,

, CODE IS io-code

;

ID IS io-individual ,

ABRANCH IS label

, POINTER IS pointer

= a 16 bit ﬁeld variable containing the number of the seized analy-

sis/line buffer. This variable has been assigned a value in an earlier COMMAND

= program label to which a jump is made if something fails.

= a structured 16 bit variable which,

execution of the statement,

= any pointer in the program to be saved. Pointers and temporary vari

ables are destroyed when the READ statement is executed.

Figure 8.58

Syntax for READ

194

Input and Output Statements

Example 83

This sample program shows how to transfer information from an I/O device to a
user program.

PROGRAM; PLEX;

....

SEIZE DEVICE CDEV, ID IS CIOID,

ABRANCH IS SEIZEERROR500;

READ, ID IS CIOID,

ABRANCH IS READERROR510;

FETCH STRING TO CTEXT, ID IS CIOID,

ABRANCH IS FETCHERROR520;

Figure 8.59

Reading and Fetching

The ﬁrst statement seizes the I/O device and assigns an analysis/line buffer. The
string variable CDEV contains the name of the I/O device. After execution of the
SEIZE statement, the number of the seized analysis/line buffer is stored as varia
ble CIOID.

The second statement transfers the information from the I/O device to analysis
buffer. In the third statement, the contents of the analysis buffer are transferred to
the user block and stored as variable CTEXT.

Overview of Alphanumeric I/O Statements

This section is a complete overview of all alphanumeric I/O statements.

I/O statements can be grouped as either alphanumeric or ﬁle-oriented statements.
Alphanumeric statements may be classiﬁed as input, output, and locking state
ments. COMMAND is an input statement used for command reception. BUSY is
an input statement needed when a command has to be rejected, if the command is
issued again, before processing is complete.

FETCH PARAMETER sends command parameters from an analysis buffer to the
user block. FETCH sends any other input data from an analysis buffer to the user
block. With CHECK, the user block can test if additional parameter blocks are
waiting in the analysis buffer. FIND allows searching for a particular string in an
analysis buffer.

I/O devices need to be locked or seized before they can be used. There are two
locking statements, SEIZE DEVICE and SEIZE DEVICE FOR, but only one
unlocking statement, RELEASE DEVICE.

Only two I/O statements are used for output of information. INSERT transfers
output strings and numbers from the user block to a line buffer. WRITE sends one
line of output text from the line buffer to the corresponding I/O device.

195

Plex-C 1

Input Output

Statements

Alphanumeric I/O

File-oriented I/O

Input

Output

Locking

COMMAND

INSERT

SEIZE DEVICE

BUSY

WRITE

SEIZE DEVICE FOR

FETCH

RELEASE DEVICE

FETCH PARAMETER

CHECK

FIND

READ

Figure 8.60

Overview of all alphanumeric I/O statements

Chapter Summary

From this chapter remember these points:

•

I/O statements transfer data between the SW units in the CP and the I/O
devices.

•

Use alphanumeric I/O statements for small quantities of data, for example,
commands and printouts.

•

Programs have to seize I/O devices before accessing them, and release them
afterwards.

References

Plex-C Language Description,
EN/LZB 101 1903 R3A,
© Ericsson Telecom 1997

AXE ASA 210 C Guide 1994,
EN/LZT 1011 837 R1, Ericsson Telecom AB, 1994

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 ﬁnd this document.

196

Chapter 9

Buffers and Structures

Introduction

This chapter extends Chapter 3, Declare Sector on page 25, and introduces addi
tional data types, some of them were added to Plex-C in 1998.

The new data types are similar to struct and union in C, that is, collections of
related variables. Structures may contain variables of many different data types
in contrast to arrays that contain only elements of the same data type. Buffers can
point to such structures.

Chapter Objectives

After completing this chapter, you are able to:

• describe purpose for and use of structures and buffers

• build and use structures

• declare and use dynamic and communication buffers

Figure 9.1

Chapter Objectives

Overview

Until 1998, Plex-C only included dynamic buffers. These are rather inﬂexible and
waste a lot of CP time. Available from 1998 with APZ 21 V1, structured buffers
make the buffer concept in Plex-C more ﬂexible and communication buffers con
siderably decrease the access times for buffers. Therefore, designers should no
longer use dynamic buffers in new design.

However, hundreds of existing SW units include dynamic buffers and the com
piler needs to support this variable type for compatibility reasons. Hence, this
chapter covers both old and new buffer types in Plex-C.

Both types of buffers store large amounts of data for a limited time period. These
buffers do not take up any space in the data store, unless the program reserves
such space with an allocation statement. If the program no longer needs the data,
it can release the buffer returning the memory to other applications.

Structured buffers deﬁne new data types in Plex-C. To this day, structured buffers
are the only possibility for deﬁning own data types in Plex-C. Both communica
tion and dynamic buffers can include data of a structured buffer type, establishing
ﬂexible data structures that meet the needs of the function being implemented.

197

Plex-C 1

Buffers

Type Definition

Variable Declaration

Structure

New & Fast

Old & Slow

Structured Buffer

Communication Buffer

Dynamic Buffer

Figure 9.2

Buffer types

Structured Buffers

Structures deﬁne data types for communication or dynamic buffers.

Structured buffers include declarations of the following variable types:

•

ﬁeld variable

•

symbol variable

•

string variable

•

one-dimensional array

•

two-dimensional array

•

structured buffer (!)

Structured buffers may include structured buffers. The variable declarations can
not include any variables properties, such as DS, CLEAR or STATIC. The varia
bles cannot be R-declared. It is not possible to specify the base address number
for a member variable in a structured buffer. Field variables may even be struc
tured on bit-level, see Variable Structures on page 38.

The names for structured buffers and member variables have to be unique in a
SW unit.

198

Buffers and Structures

BUFFER buffer-name ;

variable-declaration

AT index

;

buffer-declaration

END BUFFER ;

1..

0..

variable-declaration

AT index

;

buffer-declaration

1..

Figure 9.3

Syntax for structured buffers

Example 84

This is a small example for deﬁning a data type subscriber using a structured
buffer.

BUFFER subscriber;

BUFFER name;

STRING VARIABLE surname 15;

STRING VARIABLE givenname 15;

END BUFFER;

VARIABLE snb (32) 4;

SYMBOL VARIABLE category = (private, business, government);

VARIABLE customernumber 32;

END BUFFER;

Figure 9.4

Subscriber, a structured buffer

199

Plex-C 1

This declaration deﬁnes 2 new data types, subscriber and name. The buffers sub
scriber and name are not variables!

The structured buffer subscriber includes 4 member elements, that is, three varia
bles and a structured buffer with 2 member variables.

Variants of Structured Buffers

Similar to the union concept in the C programming language, structured buffers
permit alternative deﬁnitions of the same data and space in memory using the OR
keyword.

Structured buffers with variants “provide the means to deﬁne mutually exclusive
or overlapping substructures in a buffer.” See reference [2]. In plain English, var
iant elements of a structured buffer can replace each other completely, if they
share the same area in the memory, or partly, if they share part of some area in the
memory.

Example 85

This example deﬁnes the data type buffer1 including sub-buffer2. Buffer2 deﬁnes
two alternatives, the ﬁrst using variables D, E, and F, the other including variables
G and H. Note that G and H occupy the same space in the DS as member varia
bles D and E. It is a good idea to let member variable C in buffer1 indicate which
alternative in buffer2 currently applies.

Data Store

BUFFER buffer1;

VARIABLE A 16;

VARIABLE B 16;

VARIABLE C 16;

BUFFER buffer2;

D / G

E / H

VARIABLE D 16;

VARIABLE E 16;

VARIABLE F 16;

VARIABLE G 16;

VARIABLE H 16;

END BUFFER;

VARIABLE X 16;

END BUFFER;

Figure 9.5

A structured buffer with two variants, alternatives

200

Buffers and Structures

Memory Use of Structured Buffers

The compiler lets structured buffers start at the beginning (bit 0) of a word in the
DS (1 word = 16 bits). The compiler can, however, pack member variables to
save DS space. The word alignment applies even to subbuffers in a structured
buffer.

Some blocks contain RP software units which need to access the data in a struc
tured buffer deﬁned by the CP software units. The data type structured buffer
does not exist in RP software, and the RP software units have to access the mem
ber variables directly. In this case, it is essential that the CP software deﬁnes the
relative position of the member variables in the DS.

The AT construct speciﬁes explicitly the position of a member variable in the
structured buffer, relative to the outermost buffer declaration. The compiler
makes sure that no variables in variant buffers overlap; see reference [2]. The
position deﬁnition or index counts full words (1 word = 16 bits) and starts with
word 0 (zero).

Example 86

Figure 9.6 shows the structured buffer date without the AT construct. The com
piler packs member variables day and month in one DS word.

BUFFER date;

END BUFFER;

VARIABLE month 8;

VARIABLE year;

VARIABLE day 8;

month

year

Data Store

day

Figure 9.6

Structured buffer without explicit positions

Figure 9.7 shows the same structured buffer with the AT construct. Each member
variable starts on a new DS word.

BUFFER date;

Data Store

VARIABLE day 8 AT 0;

VARIABLE month 8 AT 1;

VARIABLE year AT 2;

END BUFFER;

day

month

year

Figure 9.7

Structured buffer with explicit positions

201

Plex-C 1

Notes

It is an error to assign the same AT position to several member variables in a
structured buffer.

Assign AT positions in ascending order. In other words, it would be illegal to
assign variable day AT position 1 before variable month AT position 0.

Communication Buffers

Structured buffers deﬁne data types for communication buffers. A communica
tion buffer is a collection of elements. A communication buffer can have one of
two data types:

•

some structured buffer

•

array of simple, non-indexed ﬁeld variables (integers)

The buffer pointer addresses an element in a communication buffer. The declare
sector contains the declaration of a buffer pointer, either as a common stored var
iable or in a record. The buffer pointer contains the relative address to the com
munication buffer.

VARIABLE bufferpointer COMMUNICATION BUFFER (

buffersize

buffername

;

)

Figure 9.8

Declaring a communication buffer pointer, syntax

Parameter buffername indicates the name of a structured buffer, that is, the data
type of the communication buffer. In this case, the compiler automatically calcu
lates the necessary space in the data store to accommodate all member variables
of the structured buffer.

If the communication buffer consists of regular integer elements, parameter buff
ersize speciﬁes the number of elements in the buffer. Individual elements in a
communication buffer are always 16 bits wide.

Restart Behaviour

If the exchange crashes, the control system restarts all SW units. See the course
Plex-C 2 for more details. Communication buffers as well as dynamic buffers do
not survive such SW restarts and lose their values and place in the data store.

Allocating Communication Buffers

Communication buffers do not require any space in the data store, unless the pro
gram allocates them. The allocation statement reserves space in the data store for
a buffer, while the free statement returns this space and dis-allocates a communi
cation buffer.

202

Buffers and Structures

ALLOCATE bufferpointer , ABRANCH IS label

, POINTER IS recordpointer

;

, POINTER IS recordpointer

;

FREE bufferpointer

Figure 9.9

Allocating and releasing a communication buffer pointer, syntax

Before the allocation and after the release, the communication buffer is unde
ﬁned.

The allocation statement seizes the necessary amount of space in the data store. If
the desired space is unavailable, the program jumps to the abranch label. If the
buffer pointer belongs to a record, specify the record pointer after POINTER IS.
Then, the allocation statement affects the current record only.

Both statements, allocate and free, destroy temporary variables and record point
ers. Only a record pointer, if speciﬁed, survives these statements.

Access to structured communication buffers is similar to that of record variables.

recordpointer :

bufferpointer :

membervariable

Figure 9.10

Access to a member element in a communication buffer

In Figure 9.10, the buffer pointer is optional. If the code declares only one buffer
pointer for a structured buffer and its members, programs may omit this pointer,
unless a record pointer is used. To make the code easier to read, it is a good idea
to specify the buffer pointer anyway.

If the elements of the communication buffer are plain integers, access is similar to
that of array elements.

203

Plex-C 1

recordpointer :

bufferpointer ( index )

Figure 9.11

Access to an element in a non-structured communication buffer

In Figure 9.10 and Figure 9.11, the record pointer is optional. If the record refer
ence is unambiguous, programs may omit the record pointer. To make the code
easier to read, it is a good idea to specify the record pointer anyway.

Example 87

This example uses a date buffer.

DECLARE;

! 3.1 TYPE DEFINITIONS !

BUFFER DATE;

VARIABLE DAY 8

AT 0;

VARIABLE MONTH 8 AT 1;

VARIABLE YEAR

AT 2;

END BUFFER;

! 3.6 COMMON STORED VARIABLES !

VARIABLE DATEBUF COMMUNICATION BUFFER (DATE);

END DECLARE;

PROGRAM; PLEX;

....

ALLOCATE DATEBUF, ABRANCH IS BUFFERROR;

....

DATEBUF:DAY = 6;

DATEBUF:MONTH = 5;

DATEBUF:YEAR = 1998;

....

FREE DATEBUF;

....

END PROGRAM;

DATA;

....

ALLOCATE DATEBUF AT BASE ADDRESS 88;

END DATA;

Figure 9.12

Type deﬁnition, declaration, allocation and use of datebuf

204

Buffers and Structures

DATEBUF

not u

sed

1 9 9 8

Figure 9.13

Communication buffer datebuf in the data store

Example 88

This example uses a buffer of twelve 16-bit integer elements, the buffer pointer
being an individual variable.

205

Plex-C 1

DECLARE;

! 3.5 RECORDS AND FILESIZES !

RECORD DEVDATA;

SYMBOL VARIABLE STATE = (IDLE, BUSY) DS;

VARIABLE NUMBUF COMMUNICATION BUFFER (12);

END RECORD;

POINTER DEVPTR (DEVDATA) R;

...

END DECLARE;

PROGRAM; PLEX;

....

DEVPTR = 4;

ALLOCATE NUMBUF, ABRANCH IS BUFFERROR540,

POINTER IS DEVPTR;

DEVPTR:NUMBUF (6) = #FF;

....

FREE NUMBUF, POINTER IS DEVPTR;

! ERROR IF DEVPTR IS NO LONGER 4 !

....

BUFFERROR540)

! TAKE STEPS TO SOLVE SITUATION !

....

END PROGRAM;

DATA;

ALLOCATE NUMBUF AT BASE ADDRESS 19;

END DATA;

Figure 9.14

Type deﬁnition, declaration, allocation and use of numbuf

The following ﬁgure shows the corresponding data structure. Variable CIND
NUM contains the current number of records in ﬁle DEVDATA. CINDNUM is
short for number of individuals.

In this example, record 4 contains a pointer to communication buffer NUMBUF
with 12 elements. The program sets element 6 of this buffer to 255.

Variable NUMBUF is undeﬁned in all other records.

206

undef

Buffers and Structures

STATE

NUMBUF

STATE

NUMBUF

STATE

NUMBUF

STATE

NUMBUF

STATE

NUMBUF

STATE

NUMBUF

STATE

NUMBUF

STATE

NUMBUF

undef

File DEVDATA

DEVPTR = 4

CINDNUM = 8

10
11

Communication buffer

0
1
2
3
4
5
6

#FF=255

not used

DEVPTR:NUMBUF

Figure 9.15

Communication buffer in a record

Dynamic Buffers

Dynamic buffers fulﬁl the same purpose as communication buffers, dynamic
buffers have existed in hundred of SW units for more than 20 years. Unfortu
nately, dynamic buffers are notoriously slow and waste too much CP time. There
fore, do not use dynamic buffers in new design. Still, it is necessary to understand
the syntax and behaviour of dynamic buffers to be able to maintain existing pro
grams.

Again, the elements of a dynamic buffer can be of two data types:

•

some structured buffer

•

array of simple, non-indexed ﬁeld variables (integers)

The buffer pointer addresses an element in a dynamic buffer. The declare sector
contains the declaration of a buffer pointer, either as a common stored variable or
in a record. The buffer pointer contains the relative address to the dynamic buffer.

Figure 9.16 shows the declaration of a dynamic buffer. The second line declares a
buffer with elements of type integer. Parameter elementsize indicates the bitsize
of each element in the buffer.

The ﬁrst line declares a buffer of type structured buffer. Parameter buffername
indicates the structured buffer, that is, the data type of the communication buffer.
In this case, it is not possible to specify the bitsize of the elements in the dynamic
buffer. Furthermore, the compiler automatically calculates the necessary space in
the data store to accommodate all member variables of the structured buffer.

207

Plex-C 1

VARIABLE

VARIABLE bufferpointer BUFFER ( buffername ) ;

bufferpointer elementsize BUFFER ;

Figure 9.16

Declaring a dynamic buffer pointer, with and without structured buffer

The program sector determines the number of elements in a dynamic buffer, not
the declare sector.

Restart Behaviour

Dynamic buffers do not survive a restart, and all the data is lost.

Allocating Dynamic Buffers

Dynamic buffers do not require any space in the data store, unless the program
allocates them. This is the same for dynamic and communication buffers.

The allocation statement reserves space in the data store for a buffer, while the
free statement returns this space and dis-allocates a communication buffer.

Figure 9.17 shows two allocation statements. The ﬁrst lacks the buffersize speciﬁ
cation. This is the recommended way of allocating a structured dynamic buffer.
Here, the compiler automatically calculates the space in the data store.

The second statement, including the buffersize speciﬁcation, applies to regular
dynamic buffers containing integer elements. Parameter buffersize speciﬁes the
number of these elements in the buffer. Remember that the buffer declaration
statement determines the size of each element in a dynamic buffer.

208

Buffers and Structures

ALLOCATE bufferpointer , ABRANCH IS label

, POINTER IS recordpointer

;

ALLOCATE bufferpointer ( buffersize ) , ABRANCH IS label

, POINTER IS recordpointer

;

Figure 9.17

Allocating a dynamic buffer, with and without structured buffer

Free, the buffer release statement, is identical for dynamic and communication
buffers.

, POINTER IS recordpointer

;

FREE bufferpointer

Figure 9.18

Releasing a dynamic buffer pointer, syntax

Before the allocation and after the release, the dynamic buffer is undeﬁned.

The allocation statement seizes the necessary amount of space in the data store. If
the desired space is unavailable, the program jumps to the abranch label.

Both statements, allocate and free, destroy temporary variables and record point
ers. Only a record pointer, if speciﬁed, survives these statements.

Access to elements of dynamic buffers is identical to that of communication buff
ers. Figure 9.19 shows the syntax for both structured and non-structured dynamic
buffers.

recordpointer :

bufferpointer :

membervariable

recordpointer :

bufferpointer ( index )

Figure 9.19

Two ways of accessing an element in a dynamic buffer

209

Plex-C 1

Example 89

This example uses a dynamic date buffer, equivalent to the communication buffer
in Example 87. Please compare both solutions. The only difference affects the
declaration of the buffer pointer, marked with an arrow in the sample code.

Keep in mind, though, that this solution is much slower than the code in Example
87.

DECLARE;

! 3.1 TYPE DEFINITIONS !

BUFFER DATE;

VARIABLE DAY 8

AT 0;

VARIABLE MONTH 8 AT 1;

VARIABLE YEAR

AT 2;

END BUFFER;

! 3.6 COMMON STORED VARIABLES !

VARIABLE DATEBUF BUFFER (DATE);

....

END DECLARE;

PROGRAM; PLEX;

....

ALLOCATE DATEBUF, ABRANCH IS BUFFERROR;

....

DATEBUF:DAY = 6;

DATEBUF:MONTH = 5;

DATEBUF:YEAR = 1998;

....

FREE DATEBUF;

....

END PROGRAM;

DATA;

....

ALLOCATE DATEBUF AT BASE ADDRESS 88;

END DATA;

Figure 9.20

Datebuf revisited, here a dynamic buffer

210

Buffers and Structures

DATEBUF

not u

sed

1 9 9 8

Figure 9.21

Dynamic buffer datebuf in the data store

Example 90

This example uses a buffer of twelve 16-bit integer elements, the buffer pointer
being an individual variable. This example is equivalent to Example 88, while
using a dynamic buffer. Please compare both solutions. Arrows indicate the dif
ferences in the code.

Keep in mind, that this solution is much slower than the code in Example 88.

211

Plex-C 1

DECLARE;

! 3.5 RECORDS AND FILESIZES !

RECORD DEVDATA;

SYMBOL VARIABLE STATE = (IDLE, BUSY) DS;

VARIABLE NUMBUF 16 BUFFER;

END RECORD;

POINTER DEVPTR (DEVDATA) R;

...

END DECLARE;

PROGRAM; PLEX;

....

DEVPTR = 4;

ALLOCATE NUMBUF (12), ABRANCH IS BUFFERROR540,

POINTER IS DEVPTR;

DEVPTR:NUMBUF (6) = #FF;

....

FREE NUMBUF, POINTER IS DEVPTR;

! ERROR IF DEVPTR IS NO LONGER 4 !

....

BUFFERROR540)

! TAKE STEPS TO SOLVE SITUATION !

....

END PROGRAM;

DATA;

ALLOCATE NUMBUF AT BASE ADDRESS 19;

END DATA;

Figure 9.22

Numbuf revisited, here a dynamic buffer

The following ﬁgure shows the corresponding data structure. Variable CIND
NUM contains the current number of records in ﬁle DEVDATA. CINDNUM is
short for number of individuals.

In this example, record 4 contains a pointer to dynamic buffer NUMBUF with 12
elements. The program sets element 6 of this buffer to 255.

Variable NUMBUF is undeﬁned in all other records. Figure 9.23 shows the mem
ory allocation in the DS for an APZ 212 processor.

212

undef

Buffers and Structures

STATE

NUMBUF

STATE

NUMBUF

STATE

NUMBUF

STATE

NUMBUF

STATE

NUMBUF

STATE

NUMBUF

STATE

NUMBUF

STATE

NUMBUF

undef

File DEVDATA

DEVPTR = 4

CINDNUM = 8

Dynamic buffer

1/0
3/2
5/4
7/6
9/8
11/10

#FF=255

DEVPTR:NUMBUF

Figure 9.23

Dynamic buffer in a record

Multiple Buffer Pointers

Here is a common question from students:

•

Is it possible to deﬁne multiple communication or dynamic buffer pointers
on the same structured buffer?

Answer: yes. But each buffer pointer declaration creates a new data structure, an
independent buffer. Compare this with ﬁles of records, where multiple record
pointers can reference the same data structure, that is, a ﬁle of records.

Buffers in Signal Descriptions

It is possible and no problem to send buffer pointers as signal data. See Figure
9.24.

Signal data D2 carries a pointer on a dynamic buffer. Indicator: B.

Signal data D3 carries a pointer on a communication buffer. Indicator: COMMU
NICATION BUFFER.

213

Plex-C 1

DOCUMENT PLAYBUFF;

SIGNAL PLAYBUFF;

! 2/15514-CNZ 211 888 REV. A !

! FUNCTION: TRAINING DOCUMENT ONLY

DO NOT USE IN REAL DESIGN WORK !

TYPE 1 CP-CP;

! SINGLE UNIQUE SIGNAL!

! POSSIBLE RETURN SIGNAL:

PLAYBUFFR !

! COMMUNICATION: SENDER:

SOMEBLOCK

RECEIVER:

ANYBLOCK !

LEVEL C BUFFER;

DATA D1 16,

! REGULAR INTEGER !

D2 B,

! PTR ON DYNAMIC BUFFER !

D3 COMMUNICATION BUFFER;

! PTR ON COMM. BUFFER !

END SIGNAL;

END DOCUMENT;

ID PLAYBUFF TYPE DOCUMENT;

CLA 2/15514;

NUM CNZ 211 888;

REV A;

DAT 98-05-07;

DES MV/ETX/PN/CDD SBRT;

RES MV/ETX/PN/CDD;

APP AS/UAB/K;

END ID;

Figure 9.24

Signal description for a ﬁctitious signal carrying buffer pointers

Use of Communication and Dynamic Buffers

Buffers are useful in a number of situations, including

•

converting protocols, such as CCITT Number 7

•

ﬁle-oriented input/output, which is described in Appendix B, File-Oriented
Input and Output, on page 197

•

transferring large amounts of data between SW units

This section discusses the last case, that is, exchange of information between SW
units. The following information applies to both communication buffers and
dynamic buffers. The text simply refers to “buffers” instead.

Local and Global Variables

All stored variables in Plex-C are global in their SW unit, meaning they are
deﬁned and accessible in all parts of the SW unit’s program, including any sub
routine or statement block.

214

Buffers and Structures

Stored variables in Plex-C are local to their SW unit, though, and other SW units
cannot access the data other than by sending and receiving a signal. There is an
exception to this last statement though: different SW units may access the same
buffer. Here is how.

Rules for Shared Access to Buffers

•

The buffer pointers have to be declared in the same way in all SW units shar
ing the buffer.

•

The structured buffer, if any, should deﬁne the same data type in all SW units
sharing the buffer.

•

Only one SW unit may allocate the buffer.

•

The SW unit allocating the buffer also has to release the buffer with the free
statement.

•

The SW units involved send each others signals carrying the buffer pointer
value. This ensures exclusive access to the buffer at any time, in other words,
there are no situations when two SW units try to read or write in the buffer
simultaneously.

Example 91

SW unit A allocates a communication buffer CCOMBUF. SW units A and B
need to have access to the buffer. SW unit A sends a signal to SW unit B granting
unit B access to the information in the buffer. The signal carries the buffer pointer
value.

Buffer pointer CCOMBUF contains the relative address of the buffer. Both units
have to declare CCOMBUF in the same way. Figure 9.25 shows this situation.

SW Unit A

SW Unit B

Data Store

Data Area

CCOMBUF

Figure 9.25

SW units A and B sharing a buffer

Figure 9.26 shows the corresponding Plex-C code. Unit A allocates a communi
cation buffer CCOMBUF. If the allocation fails, the program jumps to label
ALLOERROR. If unit A wants unit B to access the buffer, unit A sends signal
SIGMA to unit B. If unit B no longer needs the buffer, it returns signal SIGMAR

215

Plex-C 1

to unit A. If the buffer is no longer necessary in the system, unit A releases the
buffer with the free statement.

SW Unit A

SW Unit B

PROGRAM; PLEX;

....

ALLOCATE CCOMBUF,

....

ABRANCH IS ALLOERROR;

....

SEND SIGMA WITH CCOMBUF;

ENTER SIGMA WITH CCOMBUF;

EXIT;

....

ENTER SIGMAR WITH CCOMBUF;

SEND SIGMAR WITH CCOMBUF;

....

EXIT;

FREE CCOMBUF;

....

END PROGRAM;

Figure 9.26

Unit A tells Unit B it may now access the buffer

Remember that all units accessing the buffer need to declare the buffer in the
same way. Figure 9.27 gives an example.

SW Unit A

SW Unit B

DECLARE;

....

3.6 COMMON STORED VARIABLES

VARIABLE CCOMBUF

COMMUNICATION BUFFER (60);

....

END DECLARE;

Figure 9.27

Declaring the buffer pointer in units A and B

Alternative

If unit B only needs the values of some elements in the buffer, it is probably more
efﬁcient to send individual words as signal data with a regular signal. See Figure
9.28.

216

Buffers and Structures

SW Unit A

SW Unit B

PROGRAM; PLEX;

....

ALLOCATE CCOMBUF,

....

ABRANCH IS ALLOERROR;

....

SEND EPSILON WITH

ENTER EPSILON WITH

CCOMBUF (4),

TDATA1,

CCOMBUF (10),

TDATA2,

CCOMBUF (21);

TDATA3;

EXIT;

....

FREE CCOMBUF;

....

END PROGRAM;

Figure 9.28

Sharing buffer data, but not the buffer pointer

Chapter Summary

Remember these points from this chapter:

•

Structured buffers are a collection of several member variables for some
object and deﬁne new data types in Plex-C.

•

Communication buffers reference such structured buffers, or contain an array
of regular integers. In the program sector, the code has to allocate a commu
nication buffer before accessing it, and release the buffer when it is no longer
relevant.

•

Communication buffers permit access from multiple SW units. Signal send
ing ensures that only one SW unit has access to the buffer at a time.

•

Dynamic buffers serve the same purpose as communication buffers. Since
dynamic buffers are much slower than communication buffers, they should
not be used in new design any more.

References

[1]

[2]

217

Plex-C 1

218

Chapter 10

AXE Parameters

Introduction

AXE Parameters are a new ﬂexible data type available since 1997. AXE Parame
ters are not local to a block and permit global access from all parts of the
exchange. In most blocks, AXE Parameters can replace global number symbols
and market-speciﬁc parameters. This new class of parameters is easy to change
with MML commands, and avoids market corrections and recompiling the object
dump. The database management subsystem (DBS) stores the parameter values
in a central SQL database.

Chapter Objectives

After completing this chapter, you are able to:

• describe purpose for and use of AXE Parameters

• describe key terms and different classes of AXE Parameters

• write effective Plex-C code for AXE Parameters

Figure 10.1

Chapter Objectives

Purpose

Today, Ericsson invests considerable time, money and resources in adapting its
exchanges to the needs of the customer. It is difﬁcult to sell the same type of
exchange to different customers without major adaptations.

•

Optional features, for instance, require Ericsson to produce, test and deliver
different software dumps to different customers, including the additional
functions ordered by the customer. See Figure 10.2.

•

Global number symbols, which are deﬁned in the parameter list, implement
customer- or market-speciﬁc parameters. Changing the value of such a
parameter requires a market correction, that is, a patch in the data store, or a
repetition of the object 2 process. For more details see “From Plex to Object
Code” on page 18.

In both cases, Ericsson puts individual application systems together, requiring
separate compilation, testing and documentation packages. The large number of
application systems is difﬁcult to keep track of and maintain.

Ericsson can no longer afford such a waste of resources, the price pressure does
not permit to develop and deliver tailor-made solutions for each network operator.

AXE Parameters solve these difﬁculties.

219

Plex-C 1

data

Standard
APT
Product Line

data

Market-specific
Parameters

Market-specific
Features

TCS

CHS

GSS . . .

program
production
(Object 2 process)

testing

documentation +

product administration

AXE

Application System
specific to customer

Figure 10.2

Customer-speciﬁc exchanges today (simpliﬁed)

Concept

AXE Parameters provide a standard mechanism for examining and changing the
values of exchange parameters. The exchange collects the parameter values in a
central database which is part of the database management subsystem (DBS).

For direct access, database routines use the structured query language (SQL), an
international standard for database handling. CP SW units in DBS use Plex-SQL,
a Plex-C variant with SQL extensions. CP SW blocks outside DBS, however,
declare and access these exchange parameters as AXE Parameters using regular
Plex-C code.

Customer Parameter

The customer’s exchange technicians or the Ericsson support ofﬁce (ESO) can
easily change the values of AXE Parameters with generic DBS commands.
Hence, it is easy to adjust standard and optional functions to the needs of the cus
tomer. Examples:

•

the duration of a time supervision or

•

an indicator whether a call of a speciﬁc priority can be manually discon
nected or not

220

AXE Parameters

Supplier Parameter

Several customers can now receive the same product line and software dump.
ESO technicians can set AXE Parameter values differently for each customer.
Password protection prevents the customers themselves from modifying such
parameters.

Feature Parameter

The application system for each market consists of standard features and optional
features. Feature parameters are a group of AXE Parameters which determine if
an optional feature is accessible to a customer or not. Feature parameters ensure
that the operator can only use the optional features which have been contractually
agreed to. Therefore, only Ericsson's technicians may activate optional features
for the customer.

Owner and User

Many blocks can read the value of an AXE Parameter, but only MML commands
can change the value. Some block, called the Parameter Owner, is the homebase
for the AXE Parameter. If the value of the AXE Parameter changes, the Parame
ter Owner determines if the value is valid; only in this case does the DBS distrib
ute the new parameter value to all blocks reading the AXE Parameter, called the
Parameter Users.

DBS

generic MML
commands

APT

. . . .

Parameter
User
Block n

Parameter
User
Block 1

Parameter
Owner
Block

❶

New Value Okay?

Yes/No

❷

If okay

Distribute
New Value

SQL
database

AXE Parameters

Customer (exchange technician)
or Ericsson support staff

Figure 10.3

Changing the value of an AXE Parameter

221

Plex-C 1

User Code

If a command requests updating of an AXE Parameter value, the Parameter
Owner Blocks can execute some special User Code allowing for further actions.
Valid design rules apply for the Plex-C programming of the User Code, including
job buffer levels and execution time limits. See reference [2].

Redesign

Applications that wish to use AXE Parameters need to adapt and recompile the
source programs of the CP software units (SPIs). If an AXE Parameter replaces a
traditional global number symbol in the SPL, remove the corresponding Plex
statement in the SPL. An AXE Parameter deﬁned in the SPI may not appear in
the SPL or PL.

Reference [1] shows that the compiler generates a signal interface, hidden from
the source program, for the software unit so that the APZ function can:

•

Read AXE Parameter attributes (for example, value constraints)

•

Order a software unit - if classiﬁed as Parameter Owner - to verify a parame
ter value

•

Update an AXE Parameter value

Syntax

Deﬁne AXE Parameters and Parameter Sets in a new SPI sector, the Parameter
Sector. Then declare the AXE Parameters and Parameter Sets in the Declare Sec
tor in the SPI. Finally, access the AXE Parameters in the Program Sector.

Parameter Sector

This sector deﬁnes an AXE Parameter, its properties, type, value constraints and
the Parameter Set including the parameter.

222

AXE Parameters

PARAMETER;

GLOBAL PARAMETER

parameter-name

MIN =

min-value

MAX =

max-value

VALUES = (

value

, ..., value

)

DEFAULT =

default-value

UNIT = “

unit-name”

CUSTOMER
SUPPLIER
FEATURE

DISTRIBUTION =

IMMEDIATE
RESTART
APPLICATION

END PARAMETER;

CLASS =

1..

;

1..

PARAMETERSET

set-name;

1..

END PARAMETERSET;

Figure 10.4

Syntax for the Parameter Sector

Please relax. The syntax is not as bad as it appears in Figure 10.4. In the syntax
deﬁnition, all values are constant ﬁeld expressions, usually integers between 0
and 65535. The unit name is a string object of 3 characters or less. The names of
AXE Parameters and Parameter Sets may not be longer than 15 characters.

The set name speciﬁes the Parameter Set to which all parameters in the PARAM
ETERSET statement belong.

The parameter name speciﬁes the name of the parameter. A parameter name may
be ambiguous, if it is qualiﬁed with a set name. In other words, different parame
ter sets may use the same name for their parameters.

The min deﬁnition speciﬁes the minimum value allowed for the parameter. The
DBS checks this deﬁnition at parameter veriﬁcation and rejects the parameter
update, if the min deﬁnition is violated.

The max deﬁnition speciﬁes the maximum value allowed for the parameter. The
DBS checks this deﬁnition at parameter veriﬁcation and rejects the parameter
update, if the max deﬁnition is violated.

The value list deﬁnes a number of discrete values for the parameter. The DBS
checks this deﬁnition at parameter veriﬁcation and rejects the parameter update,
if the new value is not in the list.

223

Plex-C 1

It is mandatory to state the valid value range of an AXE Parameter. There are
three alternatives:

•

min deﬁnition and max deﬁnition

•

value list

•

all three deﬁnitions (although this is somewhat redundant)

The default deﬁnition is mandatory, it speciﬁes the default value for the parame
ter.

The unit deﬁnition is mandatory too, it speciﬁes the unit of the parameter. If the
parameter has no unit, specify the empty string: UNIT = ““;

The class deﬁnition is mandatory as well, choose one of three options:

•

CUSTOMER: the customer may change the parameter.

•

SUPPLIER: an operator authorised by the supplier may change the parame
ter, but not the customer.

•

FEATURE: the parameter controls the availability of an optional feature.

The distribution deﬁnition is mandatory too, choose one of three options:

•

IMMEDIATE: the DBS distributes the new value immediately.

•

RESTART: the DBS distributes the new value at the next system restart.

•

APPLICATION: the DBS distributes the new value to the Parameter Own
ers. These blocks distribute the new value to the Parameter Users at their
own discretion.

Example 92

Figure 10.5 shows a typical parameter sector. This example originates in refer
ence [4].

224

AXE Parameters

DOCUMENT TESTUPROGRAM;

PARAMETER;

PARAMETERSET CME20TCSC;

GLOBAL PARAMETER AUDISCOFFPRIOR1 ! CALLS OF PRIORITY 1 CAN BE

! AUTOMATICALLY DISCONNECTED

! AFTER BEING DETECTED AS LONG

! DURATION CALL

VALUES

DEFAULT

UNIT

CLASS

DISTRIBUTION = IMMEDIATE;

= (0, 1),

= 0,

="",

= CUSTOMER,

! VALUE

0: AUTOMATIC

DISCONNECTION NOT

ALLOWED

1: AUTOMATIC

DISCONNECTION ALLOWED!

GLOBAL PARAMETER CONFUSIONTOUT

MIN

= 20,

MAX

= 60,

DEFAULT

= 40,

UNIT

="SEC",

CLASS

= CUSTOMER,

DISTRIBUTION = IMMEDIATE;

END PARAMETERSET;

END PARAMETER;

! DEFAULT VALUE : 0, NOT ALLOWED !

! UNIT OF ALLOWED VALUES

! CLASS CUSTOMER

! VALUES FOR DISTRIBUTION

! DEFAULT VALUE : IMMEDIATE

! IF THE VALUE NEEDED IS NOT

! RECEIVED WITHIN THE SPECIFIED !

! DURATION THE SWTICH SENDS OUT A!

! CONFUSION MESSAGE

! SPECIFIED IN SECONDS

Figure 10.5

Typical parameter sector

Declare Sector

Chapter 3 on page 25 introduces the declare sector. Add the following statements
at the beginning of the declare sector; here, the CP SW unit declares the AXE
Parameters which appear in the program sector. The declare sector also deﬁnes if
the CP SW unit owns or uses the parameter.

225

Plex-C 1

DECLARE;

PARAMETER OWNER

parameter-name

user-code

PARAMETER USER

parameter-name ;

PARAMETERSET

set-name;

1..

END PARAMETERSET;

;

<user code>

AT VERIFY DO

statement-block name

AT VERIFY GOTO

label RETURN TO label

AT UPDATE DO

statement-block name

AT UPDATE GOTO

label RETURN TO label

AFTER UPDATE DO

statement-block name

AFTER UPDATE GOTO

label RETURN TO label

AT ROLLBACK DO

statement-block name

AT ROLLBACK GOTO

label RETURN TO label

1..

Figure 10.6

Syntax for the Declare Sector

The parameter owner declaration speciﬁes that the current CP SW unit owns the
parameter, that is, controls the updating of it.

The parameter user declaration speciﬁes that the current CP SW unit uses the
parameter, and that any parameter update should be distributed to the block.

The user code is optional. Only the Parameter Owner can deﬁne some user code
for an AXE Parameter. The user code permits the Parameter Owner to execute a
number of statements when the DBS

•

veriﬁes the parameter

•

updates the parameter

•

has updated the parameter

•

rolls back the parameter.

For each situation, the CP SW unit may only specify one action, either a state
ment block or a GOTO label. The usual restrictions for statement blocks, GOTO
labels and job execution apply.

The GOTO statement implies a jump to the indicated label, where a user code
sequence starts. This sequence must end with a GOTO statement to the label after
RETURN TO. Note that the compiler only checks that the program references the

226

AXE Parameters

program label, it does not validate the control ﬂow in the program. All labels
must be unique, no two parameters may share the same labels. No two parameters
should share the same user code sequence.

Example 93

Figure 10.7 shows a typical declaration and use of AXE Parameters without user
codes.

DECLARE;

PARAMETERSET CME20TCSC;

PARAMETER OWNER AUDISCOFFPRIOR1;

! AUTOMATIC DISCONNECTION

! ALLOWED/NOT ALLOWED AFTER

! DETECTION AS LONG DURATION CALL!

PARAMETER USER CONFUSIONTOUT;

! BLOCK USES THIS AXE PARAMETER !

END PARAMETERSET;

VARIABLE CELAPSEDTIME

16 DS;

! ELAPSED TIME

END DECLARE;

PROGRAM; PLEX;

IF CME20TCSC:AUDISCOFFPRIOR1 = 1 THEN

DO RELEASECALL;

FI;

IF CELAPSEDTIME > CME20TCSC:CONFUSIONTOUT THEN

DO RELEASECALL;

FI;

BEGIN RELEASECALL;

! STATEMENT BLOCK

END RELEASECALL;

END PROGRAM;

Figure 10.7

Typical declaration and access without user codes

User Code Details

See reference [2] for complete details about programming user code sequences.

227

Plex-C 1

Verify

First, the DBS veriﬁes the new parameter value against any min and max values
and/or value list. Then, if the new value is valid, the Parameter Owners execute
the verify user code.

Update

If all blocks that own the parameter accepted the new value, the DBS updates the
parameter value in all blocks that own and use the parameter. At this moment, the
Parameter Owners execute the update user code. The value is in effect, and the
programs access the value by the normal parameter syntax.

After Update

After updating the parameter value in all blocks affected, the DBS informs all
Parameter Owners about the completion of the updated. At this moment, the
Parameter Owners execute the after update user code.

Rollback

If any Parameter Owner rejects the new value during the veriﬁcation phase, the
DBS sends a rollback order to all Parameter Owners that have accepted the new
value. At this moment, the Parameter Owners execute the rollback user code. In
this case, the end result is that the value of the parameter remains unchanged.

Def erred Update

The DBS defers the update of the parameter value, if the parameter has the distri
bution properties RESTART or APPLICATION.

Restart Distribution

After the veriﬁcation phase, the DBS updates the parameter value in the Parame
ter Owners and Parameter Users during the next system restart.

Application Distribution

After the veriﬁcation phase, the DBS updates the parameter value in the Parame
ter Owners only. One of the Parameter Owners initiates the update in the Parame
ter Users with the Plex-C procedure DISTRIBUTE.

Example 94

Figure 10.8 shows typical declarations and Figure 10.9 typical use of AXE
Parameters with user codes.

228

AXE Parameters

DECLARE;

PARAMETERSET CME20TCSC;

PARAMETER OWNER AUDISCOFFPRIOR1

AT VERIFY GOTO EXAMVERIFYCODE

RETURN TO RETVERIFYLAB1,

AT ROLLBACK GOTO EXAMROLLBACK

RETURN TO RETROLLBACKLAB2,

! AUTOMATIC DISCONNECTION

! ALLOWED/NOT ALLOWED AFTER

! DETECTION AS LONG DURATION CALL!

! BLOCK OWNS THIS AXE PARAMETER !

! ADDITIONAL CHECKS PERFORMED

! IN APPLICATION-DEFINED

! USER CODES

AFTER UPDATE GOTO EXAMPOSTUPDATE

RETURN TO RETPOSTUPDATELB3,

AT UPDATE GOTO EXAMUPDATE

RETURN TO RETUPDATELB4;

PARAMETER USER CONFUSIONTOUT;

END PARAMETERSET;

VARIABLE CELAPSEDTIME

16 DS;

END DECLARE;

! BLOCK USES THIS AXE PARAMETER !

! ELAPSED TIME

Figure 10.8

Typical declarations with user codes

This example continues in Figure 10.9 showing the corresponding program sec
tor.

229

Plex-C 1

PROGRAM; PLEX;

IF CME20TCSC:AUDISCOFFPRIOR1 = 1 THEN

DO RELEASECALL;

FI;

IF CELAPSEDTIME > CME20TCSC:CONFUSIONTOUT THEN

DO RELEASECALL;

FI;

! BEGIN OF OPTIONAL USER CODES

EXAMVERIFYCODE)

! PLACE HERE

! VERIFICATION CODE TO BE EXECUTED!

GOTO RETVERIFYLAB1;

EXAMROLLBACK)

! PLACE HERE

! ROLLBACK-CODE TO BE EXECUTED

GOTO RETROLLBACKLAB2;

EXAMPOSTUPDATE)

! PLACE HERE

! POSTUPDATE-CODE TO BE EXECUTED !

GOTO RETPOSTUPDATELB3;

EXAMUPDATE)

! PLACE HERE

! UPDATE-CODE TO BE EXECUTED

GOTO RETUPDATELB4;

BEGIN RELEASECALL;

! STATEMENT BLOCK

END RELEASECALL;

END PROGRAM;

Figure 10.9

Typical program sector with user codes

Parameter Access

The following syntax is available for expressions in the program sector; see Fig
ure 10.10. Thus, programs can access parameter values and other parameter
information.

The set name is only optional, if the parameter name is unique among all names
in the SPI.

The optional attribute states the type of parameter information retrieved. If omit
ted, VALUE is assumed.

230

AXE Parameters

PROGRAM; PLEX;

parameter-name

.attribute

;

<attribute>

set-name :

VALUE

SETNAME

PARAMETERNAME

RELATION

UNIT

CLASS

DISTRIBUTION

Figure 10.10

Syntax for accessing AXE Parameters

Application Parameter Distribution

The following procedure is only available for AXE Parameters of distribution
type APPLICATION; see Figure 10.11. The statement allows Parameter Owners
to broadcast the new parameter value to all Parameter Users.

Only Parameter Owners may use the Plex-C procedure DISTRIBUTE.

This procedure destroys all temporary variables with the exception of the pointer
in the optional POINTER IS clause. After the execution, the optional CODE IS
clause has returned an APZ status code in the user status variable.

See reference [2] for further information.

PROGRAM; PLEX;

parameter-name

set-name :

POINTER IS

user-pointer

;

DISTRIBUTE

CODE IS

user-status

Figure 10.11

Syntax for parameter distribution

231

Plex-C 1

Rules

For complete design rules on AXE Parameters see references [4] and [6].

P arameter Sets

A Parameter Set is a group of AXE Parameters that have the same scope. An
AXE Parameter can only be part of one Parameter Set, but different Parameter
Sets can use the same parameter name. The parameter names in a Parameter Set
must be unique.

The scope for AXE Parameters can be a subsystem (ABC class ANT or ANZ), a
set of parts (CRT or CRZ, only with AM) or complete source systems (APT, APZ
or AXE). Blocks (CNT, CNZ) or units (CAA) do not establish such a scope. All
Parameter Owners of an AXE Parameter must reside in the original scope of the
Parameter Set. However, blocks outside the scope may access the parameter and
become Parameter Users.

It is not possible to mix AXE Parameters of class CUSTOMER and SUPPLIER
in the same Parameter Set.

P arameter SetNames

The name of a Parameter Set must relate to a registered product. Designers can
not deﬁne new SetNames at will. SetNames are centrally administered in a list
available through DRtool. A new SetName can be obtained from the person
responsible for this document. See reference [4].

Parameter SetName for Customer Parameter

SymbolicnameC, where Symbolicname refers to a registered product and C is the
set for customer parameters. Example:

CME20HRSC

This set contains customer parameters for the HRS subsystem in GSM.

Parameter SetName for Supplier Parameter

SymbolicnameS, where Symbolicname refers to a registered product and S is the
set for supplier parameters. Example:

SSFAMBASCALLS

This set contains supplier parameters for the SSF-AM ‘Basic Call Handling’, a
CRT system part.

Documentation

For each product which deﬁnes such a scope for AXE Parameters, create docu
ments listing and describing those parameters. These documents are application
informations (AI; decimal class: n/155 18-AXE/APT/ANT/CRT etc.), but they
are quite different from the usual 2/application informations (2/AI; decimal class:
n/155 18-CNT...) on block level. A new, speciﬁc document instruction is in prep
aration. Somebody clearly deserves to be locked up in Ericsson’s designer dun
geons for creating this confusion.

In any case, create separate AIs for the Customer and the Supplier parameters.

232

AXE Parameters

K e y T erms

AXE Parameter

A parameter with a deﬁnition and value that is common to one or more central
software units. Some classes of AXE parameters allow value changes by com
mand.

An AXE Parameter is identiﬁed by the parameter name and the name of the

➞

Parameter Set. The AXE Parameter concept supports numeric values (0

65535) only.

The name of an AXE Parameter may not be longer than 15 characters.

Parameter Set

A group of

➞

AXE Parameters that have the same scope. For example, a set of

parameters may be deﬁned for a function, another for a subsystem, and another
for an application system.

The name of a Parameter Set may not be longer than 15 characters.

Customer Parameter

A class of

➞

AXE Parameters which the customer (operator, exchange techni

cian) may change by command.

Supplier Parameter

A class of

➞

AXE Parameters which only Ericsson staff may change by com

mand. The customer may not change the value of this class of parameters (pass
word protection).

A Supplier Parameter is not used to control

➞

Optional Features.

Feature Parameter

A class of

➞

AXE Parameters determining whether an

➞

Optional Feature is

available to the customer.

Only Ericsson personnel may enable and disable optional features using com
mands. The customer has no authority to change the value of this class of param
eters (password protection).

Distribution Type, Immediate

Parameters with Distribution Type IMMEDIATE permit immediate updating of
the parameter values in the parameter-owner and parameter-user blocks.

Distribution Type, Restart

Parameters with Distribution Type RESTART update their values in the parame-
ter-owner and parameter-user blocks at the next system restart.

Distribution Type, Application

Parameters with Distribution Type APPLICATION update their values in the
parameter-owner blocks only. The parameter-owner blocks are responsible for
distributing the updated values to other blocks in the application system.

Parameter Owner

A block which veriﬁes an AXE parameter value before storing it and distributing
it in the system. By deﬁnition, a Parameter-Owner block may also use the param
eter.

233

Plex-C 1

Parameter User

A block that references an AXE parameter. The block does not verify the value of
the AXE parameter it uses.

Chapter Summary

From this chapter you should remember these points:

•

AXE Parameters are a useful, ﬂexible and global datatype.

•

Both Ericsson and the customer can easily change the parameter values
stored in an SQL database in the DBS.

•

AXE Parameters are organised in Parameter Sets which have a certain scope,
that is a registered product in the AXE system hierarchy.

•

Parameter Owners check the new value when a parameter is updated by
command. Parameter Users only refer to the parameter value.

•

The new Parameter Sector deﬁnes the type and properties of an AXE Param
eter.

•

The Declare Sector declares the parameter for the program sector in the SPI.

References

[1]

[2]

[3]

[4]

[5]

Modiﬁcation of AXE Parameter and AXE Parameter Set Deﬁnitions (design r.)
ETX 102 60-1297 Uen
© Ericsson Utvecklings AB 1996

[6]

234

Chapter 11

Data Structures

Introduction

When writing a program, it is very important to structure the data in a suitable
way. The structure of the data affects the readability, maintenance and execution
time of a programming task. In the declare sector, data is structured in arrays and
records. This chapter describes how data may be structured by using linked lists,
or by implementing logic in the data.

Chapter Objectives

After completing this chapter, you are:

• able to use the principles of single- and double-linked lists

• familiar with the differences between implementing logic in

the data or program structure

Figure 11.1

Chapter Objectives

Linked Lists in the Subscriber Switch

Some of the function blocks in AXE exchanges contain hardware devices. For
example, the function block LI contains line interface circuits (LIC), and the
function block KR2 contains key-set code receivers (KRC). When there are a
number of the same hardware device in a function block, each one is called a
device individual.

The central software for blocks with hardware must be able to supervise its hard
ware devices, for example, to check whether a device individual is idle (i.e., avail
able) or not. To implement this check, the central software in blocks with
hardware must have a ﬁle, where each device individual has one corresponding
record.

Assume an exchange where the KR2 block contains 200 KRCs. In the software
for this KR2 block there is a ﬁle, called DEVICEDATA, which contains 200
records, one record for each KRC (see Figure 11.2).

235

Plex-C 1

KRC-0

KRC-1

KRC-2

KRC-3

KRC-199

(KRC)

Regional

(KRR)

File

199

Hardware Devices

Hardware

Function Block KR2

Software

Central
Software
(KRU)

DEVICEDATA

STATE

Figure 11.2

Function block KR2 containing 200 device individuals and one record for each
device individual.

In Figure 11.2, record number 0 belongs to hardware device KRC-0, record
number 1 belongs to hardware device KRC-1, and so on. In Figure 11.2, also note
that each record includes several variables. One of these variables is the variable

STATE. The value of this variable indicates the state of the device individual that
corresponds to this record.

Assume that a function block contains many device individuals. The task is to
write a program which selects an idle device. The program will search in the ﬁle,
trying to ﬁnd a record where the variable STATE has the value IDLE.

One way of doing this is to start checking if the device with the highest number is
idle. If the device is idle, the program takes it, if not, the program tries the device
with the next lowest number. In other words, create a FOR FIRST loop over all
records in the ﬁle.

Unfortunately, this solution is very inefﬁcient and should be avoided, particularly
if the ﬁle contains a large number of records.

Some disadvantages of this solution are:

236

Data Structures

•

when the trafﬁc level is low, only devices with high numbers are used

➯

uneven usage of the hardware.

•

as the trafﬁc load increases more and more devices need to be checked
before an idle one is found

➯

long scanning time.

•

when there is no idle device, a check of all devices will be performed

➯

waste of time.

So, how to select an idle device? If the number of device individuals is or can be
large, then it is a good solution to use linked lists. The idea is to link all records
belonging to idle devices of the same type together. The program searches only in
the list containing idle records.

To make it possible to check the beginning and the end of the list, two variables
outside the records are used: one that indicates the ﬁrst idle record in the list; and
one that indicates the last idle record. See Figure 11.3.

IDLE

CFIRST

CLAST

STATE

BUSY

Figure 11.3

A linked list

The ﬁle shown in Figure 11.3 has seven records. Three of these are idle and have
been linked together. The idle records in Figure 11.3 are numbers one, two and
ﬁve. The stored ﬁeld variable CFIRST indicates the ﬁrst idle record in the list (1)
and variable CLAST the last idle record (5).

237

Plex-C 1

Single-Linked Lists

In single linked lists (shown in Figure 11.4), each record contains a variable that
indicates the number of the next idle record in the ﬁle of records. In blocks with
hardware, each record corresponds to a hardware device.

IDLE

#FFFF

CLAST

CFIRST

STATE

Figure 11.4

A single-linked list

In Figure 11.4, the content of the individual variable NEXT indicates the number
of the next idle record in the list. Variable CFIRST states the ﬁrst, and variable
CLAST the last idle record in the list. Please note that Figure 11.4 only shows the
idle records in the ﬁle of records.

The value of the variable NEXT in the last record of the linked list, is equal to the
hexadecimal value FFFF. This is the largest value that can be stored in a 16-bit
variable. The number FFFF indicates that there is no following record in the list.

Often a local number symbol ZNIL with the value #FFFF is used to mark the end
of a linked list.

For ﬁles of records using R pointers, the maximum value is the construct RNIL,
whose current value depends on the register size of the target processor.

To remove an idle device, its corresponding record is fetched from the beginning
of the list. Records belonging to devices that become idle, are inserted at the end
of the list. This is called the “ﬁrst in, ﬁrst out” method.

Before inserting or removing a device from the list, a check must be made to
determine whether the list is empty or not. If the list is empty, the condition
CFIRST = #FFFF is met.

Example 95

This PLEX program removes the ﬁrst idle device in the linked list shown in Fig
ure 11.4.

This could be performed in the following way, under the condition that the linked
list has at least two elements:

238

Data Structures

PROGRAM; PLEX;

....

IF CFIRST /= #FFFF THEN

DEVPOINTER = CFIRST;

CFIRST = DEVPOINTER:NEXT;

DEVPOINTER:STATE = BUSY;

FI;

Removing an Idle Device

At the beginning, a check is made to determine whether the list is empty or not. If
the list is not empty, the code after IF ... THEN is executed.

In this case, the pointer DEVPOINTER gets CFIRST’s value. (DEVPOINTER is
the pointer to this ﬁle of records.) After execution of this statement, the pointer
DEVPOINTER indicates the ﬁrst idle record in the linked list, which is record
number 7 according to the last example.

In the next line, the variable CFIRST is set to the number of the second record in
the list (record number 15). This is the ﬁrst record in the new list.

In the following line, the variable STATE in record number 7 gets the value
BUSY, which indicates that the device is busy. After execution of the statements,
the list looks like in Figure 11.5.

The same code segment could be used, if the linked list had only one element.
However, the variable CLAST has to be set to #FFFF after removing the last ele
ment of the list.

IDLE

#FFFF

CLAST

CFIRST

DEVPOINTER

BUSY

STATE

Figure 11.5

The list after the ﬁrst device has been removed

Double-Linked Lists

Suppose that a certain device is to be removed from the middle of the linked list,
for example, for repair. In that case, it is necessary to put the list together again

239

Plex-C 1

with the remaining devices. It is possible, but difﬁcult and time-consuming to
write PLEX statements that remove a device from the middle of a single- linked
list. It is much easier to remove the device, if the list is double-linked.

The most signiﬁcant difference between a single- and a double-linked list is that
the double-linked list contains an individual variable that indicates the previous
record in the list. In Figure 11.6, the variable PREVIOUS indicates the previous
record in the list.

IDLE

CLAST

CFIRST

#FFFF

STATE

Figure 11.6

A double-linked list

Example 96

Consider the linked list in Figure 11.6 and the three pointers DEVPOINTER,
APOINTER and BPOINTER declared for this ﬁle.

In this example, the task is to write PLEX statements that remove a record from
the middle of the list. The number of the record to be removed is stored in varia
ble TBLOCK. Assume that it is record number 19 that is to be removed. Assume
also that the program has checked that the record is not the ﬁrst or the last in the
list. The program should also set the STATE to BLOCKED in the removed
record.

240

Data Structures

DECLARE;

....

RECORD DEVICEDATA;

SYMBOL VARIABLE STATE =

(IDLE, BUSY, BLOCKED) DS;

VARIABLE NEXT 16 DS;

VARIABLE PREVIOUS 16 DS;

END RECORD;

POINTER DEVPOINTER (DEVICEDATA);

POINTER APOINTER (DEVICEDATA);

POINTER BPOINTER (DEVICEDATA);

....

VARIABLE CFIRST 16 DS;

VARIABLE CLAST 16 DS;

VARIABLE TBLOCK;

....

END DECLARE;

PROGRAM; PLEX;

....

DEVPOINTER = TBLOCK;

APOINTER = DEVPOINTER:PREVIOUS;

BPOINTER = DEVPOINTER:NEXT;

APOINTER:NEXT = BPOINTER;

BPOINTER:PREVIOUS = APOINTER;

DEVPOINTER:STATE = BLOCKED;

Figure 11.7

Remove a Device from the Middle of the List

At the beginning, the pointer DEVPOINTER receives the value of the variable
TBLOCK, which is equal to 19 in this example. After execution of this statement,
DEVPOINTER indicates record number 19.

In the second line, the pointer APOINTER receives the value of the variable
DEVPOINTER:PREVIOUS. In the current record, variable
DEVPOINTER:PREVIOUS is equal to 2.

In the next line, the pointer BPOINTER receives the value of the variable
DEVPOINTER:NEXT. In the current record, variable DEVPOINER:NEXT is
equal to 4.

241

Plex-C 1

After execution of these three statements, the pointers have the positions shown
in Figure 11.8.

IDLE

CLAST

CFIRST

#FFFF

APOINTER

DEVPOINTER

BPOINTER

#FFFF

STATE

Figure 11.8

Pointer positions

Finally, the variable APOINTER:NEXT is set to the value of BPOINTER. In this
example, the variable NEXT in record number 2, receives the value 4. See Figure
11.9.

IDLE

#FFFF

CLAST

CFIRST

#FFFF

APOINTER

DEVPOINTER

BPOINTER

STATE

Figure 11.9

Removing a record

The following line sets BPOINTER:PREVIOUS to the value of APOINTER.
Then, variable PREVIOUS in record number 4 is equal to 2. See Figure 11.10.

242

Data Structures

IDLE

CLAST

CFIRST

#FFFF

APOINTER

DEVPOINTER

BPOINTER

#FFFF

STATE

Figure 11.10

Removing a record

The two subsequent statements (APOINTER:NEXT = BPOINTER and
BPOINTER:PREVIOUS = APOINTER) remove record number 19 and put the
list together again. After execution of these two statements, the list will look like
in Figure 11.11.

IDLE

#FFFF

CLAST

CFIRST

#FFFF

STATE

Figure 11.11

Contents of the list after the device has been removed

In the last line, variable STATE in record number 19, receives the value
BLOCKED.

243

Plex-C 1

Implementing Logic in the Data or in the
Program Structure

It is often better to put the logic in the data instead of in the program. The pro
gram will usually run faster and be easier to understand if the logic is in the data.

The ordinal number of a speciﬁc day in the year shall be determined. For exam
ple, the ﬁfth of January has the ordinal number 5, and the ﬁfth of February has the
ordinal number 36. The calculation will be solved with two programs, one where
the logic is implemented in the data, see Example 97, and one where the logic is
implemented in the program, see Example 98. The examples highlight the advan
tage of implementing logic in the data. In these examples, the ordinal number will
only be calculated for normal years of 365 days, not for leap years.

Example 97

In this example, the logic is implemented in the data. A two-dimensional array
called CNORMALYEAR will be used for the data. In the array there will be one
row for each month. The contents of the array are shown in Figure 11.12.

CNORMALYEAR (13, 32)

Jan

Feb

Mar

Apr

118 119 120

May

121 122 123 124 125 126 127

148 149 150 151

Jun

152 153 154 155 156 157 158

179 180 181

Jul

Month

182 183 184 185 186 187 188

209 210 211 212

Aug

213 214 215 216 217 218 219

240 241 242 243

Sep

244 245 246 247 248 249 250

271 272 273

Oct

274 275 276 277 278 279 280

301 302 303 304

Nov

305 306 307 308 309 310 311

332 333 334

Dec

335 336 337 338 339 340 341

362 363 364 365

Day

Figure 11.12

Contents of the array CNORMALYEAR

244

Data Structures

The array indices follow zero numbering, which does not do any harm, since nei
ther month 0 nor day 0 exist.

DECLARE;

VARIABLE CNORMALYEAR (13, 32) 16 DS;

VARIABLE CNUMBER 16 DS;

VARIABLE CMONTH 16 DS;! VALUE RANGE 1..12 !

VARIABLE CDAY 16 DS; ! VALUE RANGE 1..31 !

....

END DECLARE;

Logic in the Data – Declarations

The ordinal number of the date can be calculated with the following statement.

PROGRAM; PLEX;

....

CNUMBER = CNORMALYEAR (CMONTH, CDAY);

Logic in the Data – Ordinal Number

For example, this statement determines the ordinal number for the fourth of
December:

PROGRAM; PLEX;

....

CNUMBER = CNORMALYEAR (12, 4);

Logic in the Data – Ordinal Number of December 4th

After execution of the statement, the variable CNUMBER is equal to 338.

Please note that the calculation involves only a single statement, in other words,
the calculation is very fast.

Example 98

This example implements the logic in the program.This is a possible way of cal
culating the ordinal number of a speciﬁc date.

245

Plex-C 1

DECLARE;

VARIABLE CNUMBER 16 DS;

VARIABLE CMONTH 16 DS; !VALUE RANGE 1..12!

VARIABLE CDAY 16 DS; ! VALUE RANGE 1..31!

CADDMONTH 16 DS;

END DECLARE;

PROGRAM; PLEX;

....

CNUMBER = CDAY;

ON CADDMONTH FROM 1 UPTO CMONTH DO

CASE CADDMONTH IS

WHEN 2 DO

CNUMBER = CNUMBER + 31;

WHEN 3 DO

CNUMBER = CNUMBER + 28;

WHEN 4 DO

CNUMBER = CNUMBER + 31;

WHEN 5 DO

CNUMBER = CNUMBER + 30;

WHEN 6 DO

CNUMBER = CNUMBER + 31;

WHEN 7 DO

CNUMBER = CNUMBER + 30;

WHEN 8 DO

CNUMBER = CNUMBER + 31;

WHEN 9 DO

CNUMBER = CNUMBER + 31;

WHEN 10 DO

CNUMBER = CNUMBER + 30;

WHEN 11 DO

CNUMBER = CNUMBER + 31;

WHEN 12 DO

CNUMBER = CNUMBER + 30;

OTHERWISE DO;

ESAC;

NO;

....

END PROGRAM;

Figure 11.13

Logic in the Program

Assume that, as in Example 97, the task is to determine the ordinal number of the
fourth of December (CMONTH = 12, CDAY = 4). The program in Figure 11.13
has to repeat the loop 12 times. The calculation takes much longer than in Exam

246

Data Structures

ple 97. This program in Figure 11.13 is also much more difﬁcult to read and
understand.

Even if an IF statement was used, the solution would be considerably worse,
compared to the solution in Example 97.

Chapter Summary

From this chapter remember the following points:

•

how to structure data into a linked list

•

the statements for inserting and removing devices from a linked list.

•

the difference between a double- and a single-linked list

•

the difference between implementing logic in the data or in the program

247

Plex-C 1

248

Chapter 12 Design Environment

Introduction

During the process of Unit Design and Basic Testing, the designer needs a large
number of tools. This chapter presents and brieﬂy introduces the most relevant
tools available for preparing and checking Plex-C programs.

Chapter Objectives

After completing this chapter and the related exercises, you are able to use
the following tools included in the APStools platform:

• APS toolbox

• Analyzetool

• EmuTool

• PlexView

Figure 12.1

Chapter Objectives

This text assumes that you are familiar with the basic operations in the OpenWin
dows environment as well as the FileManager tool. Both systems are covered in
any basic UNIX course.

APStools

APS is an abbreviation for APZ Programming System. It provides a modern
design environment containing different tools to help the AXE 10 software
designer. The tools include an editor, syntax analyser, code generator, code emu
lator, source code browser, ﬁle handling tool, and access to centralised libraries
on IBM mainframe computer systems.

APS exists in two versions. APS3 is accessible from IBM mainframe terminals,
and is not covered in this chapter. APStools is the up-to-date version for UNIX
workstations presented on the following pages. All details are based on APStools
release 13.1 or APS System 1.0.

APS Toolbox

All tools can be reached from the APS Toolbox from the OpenWindows environ
ment on UNIX workstations. As your local OpenWindows system may vary from
the following shown in Figure 12.2, take the picture as an example only and try to
ﬁnd your local entry APSTools (or similar) by browsing all submenus of the
Workspace pop-up menu on your screen.

249

Plex-C 1

Figure 12.2

Starting APStools from the Workspace menu

On UNIX workstations, start APStools by entering command tbxtool in a shell
tool window. Many UNIX ﬁle systems put this program in a directory
/usr/local/aps13.1/bin or similar.

After clicking on APSTools, the following collection of icons appears.

250

Design Environment

Figure 12.3

APS Toolbox 13.1 with its default platform tools

In the top left corner, you will usually ﬁnd the IntroDS icon when you start the
APS Toolbox for the ﬁrst time.

Figure 12.4

IntroDS - introduction and help features in APStools

IntroDS provides easy-to-use access to introductory information and lists of
available courses. IntroDS is a website in Ericsson’s intranet accessible via Net-
scape.

IntroDS connects you with the various on-line manuals available for each tool.
IntroDS contains some general information on APStools too. Cross-references or
hypertext links provide quick access to additional information for each under
lined keyword. Click on IntroDS now; see Figure 12.5.

251

Plex-C 1

Figure 12.5

IntroDS and on-line help browser

Click on APStools 13.1 to ﬁnd out about available material for this release of
APStools.

Figure 12.6 shows the IntroDS webpage for APStools 13.1 with links to user and
installation manuals, product revision information, training centres and presenta
tion material.

252

Design Environment

Figure 12.6

IntroDS: website for APStools 13.1

Click on User Manuals to ﬁnd help documents for each tool. See Figure 12.7.

253

Plex-C 1

Figure 12.7

IntroDS: user manuals for APStools

This window shows an alphabetic list of all tools in the AXE software design
environment.

Click on analyzetool to ﬁnd out which material is available on this tool for editing
and checking Plex-C program ﬁles. See Figure 12.8.

254

Design Environment

Figure 12.8

IntroDS: manuals for Analyzetool

Click on the manual icon to open the help document. See Figure 12.9.

255

Plex-C 1

Figure 12.9

IntroDS: manual page for Analyzetool

The window shows the manual page only. Note the reference to the Analyzetool
User’s Guide under Description. This SGML document explains all menus and
features of the tool. It is accessible via APSDocs in the APS toolbox.

Customising APStools

APStools provides access to several dozen tools. It is quite impossible to see all
icons in the toolbox at the same time. The user can set the range of icons dis
played by default. To select the most relevant tools, use Default Tools ... from the
Edit submenu in your APS Toolbox.

256

Design Environment

Click in the Default Tools window on any tool you would like to add to your tool
box (Figure 12.10). A frame appears around the tool name selected.

Likewise, click in the Default Tools window on any tool you would like to
remove from the toolbox.

Figure 12.10

Opening the Default Tools window from the APS Toolbox

For this course and basic programming in general, please select the following
tools and icons:

•

APStools Docs

•

Analyzetool

•

Apsprint

•

Compresstool

•

DRtool

•

EDMLtool

•

EmuTool/Apzemulator

•

FileManager

•

IntroDS

•

PlexView

•

Text and Graphics

•

Tomax

Figure 12.11 shows the result of these settings.

257

Plex-C 1

Figure 12.11

Useful minimum selection for your APS Toolbox

Now choose File/Save As and store these settings under the name Plex-C 1 to be
able to reload them later.

Figure 12.12

Saving the toolbox settings with File/Save As

258

Design Environment

To make Plex-C1 the standard toolbox that pops up whenever you start APStools,
use the Properties window.

Figure 12.13

Setting the toolbox properties

Note that you can also determine whether a single or a double click will open a
tool in your toolbox. Click on the Apply button to conﬁrm the new settings in this
window. See Figure 12.14.

259

Plex-C 1

Figure 12.14

Applying the changes in the Properties window

The following Figure 12.15 shows the ﬁrst row of icons in the Plex-C 1 setting.

Figure 12.15

APStools: the icons for APS Docs, Analyzetool, APSprint, and Compresstool

APSDocs

starts a regular OpenWindows FileManager tool, showing the
home directory for the reference and user guides for all availa
ble tools.

Analyzetool

starts a multi-purpose tool used for editing, syntax checking
and compiling Plex programs (see page 262 for more details).

APSprint

allows you to format and print any kind of document on your
UNIX printer. The tool accepts Plex code, ASCII ﬁles, ﬂow
charts, EDML and postscript ﬁles as input.

Compresstool

decreases the size of your ﬁle and compresses it, if hard

disk space is limited. If the original ﬁle is already compressed,
the tool will uncompress it.

Note that you can drag and drop any ﬁle from your FileManager tool on to the
Analyzetool, APSprint or Compresstool icons in order to edit, print, or compress
it. Drag-and-drop is supported by most APStools.

260

Design Environment

This is the second row of icons in the “Plex-C 1” toolbox.

Figure 12.16

APStools: the icons for DRtool, EDMLtool, EmuTool, and FileManager

DRtool

provides user-friendly access to up-to-date design rules for
general as well as project-speciﬁc issues in Plex programming.

EDMLtool

allows text editing, formatting and previewing of all documents
written in Ericsson’s Document Mark-up Language.

EmuTool

starts the Emulator, a software testing tool emulating the
behaviour of an AXE 10 exchange (cf. page 260 for more
details).

FileManager

starts the regular OpenWindows File Manager.

Finally, the third row of icons in the “Plex-C 1” toolbox.

261

Plex-C 1

Figure 12.17

APStools: the icons for IntroDS, PlexView, Text and Graphics (TaG) and Tomax

IntroDS

provides user-friendly access to general information and man
ual pages for all tools in your toolbox (see above for details).

PlexView

allows you to browse all Plex documents including SPI, SS,
PL, and SD for compiled software units. The code can be dis
played in both Plex and ASA (see page 276 for details).

TaG

Text and Graphics is a modern editor and formatter for the new
documentation standard SGML (Standard General Mark-up
Language).

Tomax

Browser for method documentation based on the world-wide
web (WWW). Provides easy access to process descriptions,
document and work instructions.

Editing and Analysing Plex documents

If the FileManager is not running on your OpenWindows workspace already, start
the FileManager by clicking once or twice on the corresponding icon in
APStools. You should keep the FileManager tool to drag and drop ﬁles to the
other icons in your toolbox.

Figure 12.18

FileManager icon

The File Manager application includes two windows: the main window and the
wastebasket, see Figure 12.19.

Note: this chapter does not introduce or discuss the FileManager. Please refer to a
UNIX course or documentation on OpenWindows instead.

262

Design Environment

Figure 12.19

FileManager main window and wastebasket

Use File/Create Folder to create a new directory for all ﬁles you will need for
this course. Click twice on the name of the new folder, erase the default name and
type the new folder name ‘Plex-C1’ (no spaces please) to rename the directory.

Figure 12.20

Creating a new folder or directory with the FileManager

Copy the sample source program information ﬁle edeclare.program from your
teacher’s directory to your Plex-C1 folder. Ask your instructor for the full ﬁle
path and any advice if needed.

263

Plex-C 1

Figure 12.21

FileManager with Plex-C1 directory and the sample edeclare.program

The Analyzetool edits, checks and formats any Plex document. Drag and drop the
icon for edeclare.program to the toolbox icon labelled Analyze to start this appli
cation.

Figure 12.22

Starting the Analyzetool and loading the ﬁle edeclare.program (with drag and
drop)

The Analyzetool pops up on your screen and displays the loaded ﬁle in the centre
of its window. The input ﬁle is indicated in the ﬁeld marked with ’Source:’.

264

Design Environment

Figure 12.23

Analyzetool with input ﬁle edeclare.program

The centre of the window includes a regular text editor; in fact its functionality is
almost identical to the OpenWindows textedit program. The lower part of the
window is reserved for status messages and result codes.

To access the text editing functions, you may use the function keys Cut, Copy,
Paste, Undo, Delete and Backspace on your workstation keyboard.

Additional functions are accessible from pop-up menus. Press the right mouse
button in the middle of the window. Figure 12.24 shows the text pane pop-up
menu and its edit and undo submenus.

265

Plex-C 1

Figure 12.24

Analyzetool pop-up window with edit and undo submenus

In addition to these general features, the Analyzetool offers help in writing syn
tactically correct Plex documents. The most important Plex commands are found
under the menu item Plex Extensions.

Figure 12.25 shows an easy way of inserting a signal sending statement into the
current document. Note that this function will only provide the most common
statements used under typical conditions.

266

Design Environment

Figure 12.25

Analyzetool pop-up window with Plex Extensions and signalling submenus

Another special and useful feature is the capitalisation routine which can be
found under the pop-up menu entry Extras. Some designers prefer to write the
entire Plex ﬁle in lower-case letters, and capitalise it at the last moment.

Figure 12.26

Converting lower-case to upper-case characters with Extras/Capitalize

267

Plex-C 1

In addition to these editing functions, the Analyzetool can also check your docu
ment for syntactical correctness. Click on the Analyze item in the Start pull-
down menu to activate this feature. The Analyzer generates three output ﬁles, if
no error was found. One of these ﬁles is a nicely formatted list ﬁle (*.listpgm),
another the analysed source program (*.anapgm).

Figure 12.27

Starting the syntax analyser from the Start pull-down menu

The lower pane of the Analyzetool window shows the number of syntactical
errors and warnings in your ﬁle, in addition to other encouraging information
such as ‘fatal error’ at the very bottom of the window.

Figure 12.28

Result of the syntax check in the lower pane of the Analyzetool

The Error window appears near the top of your screen.

268

Design Environment

Figure 12.29

Error window of the Analyzetool

In the Error window, click on Next to view the ﬁrst fault found in your ﬁle. Then
use the Next and Previous buttons to browse back and forth between the errors in
the source ﬁle. Note that the tool highlights the likely origin of the error in the
main window.

Figure 12.30

Selecting and viewing errors in the Analyzetool Main and Error windows

To get more information on the symptoms, reasons, and possible corrections for a
syntax fault, click on Help on message ... in the Error window.

269

Plex-C 1

Figure 12.31

Additional information on syntax faults is displayed in the Message Help window

If desired, you can add signals to be included in the syntax check of your source
program ﬁle. Click on Options/Signal Handling ... to open the pop-up window.

Figure 12.32

Setting the signal handling properties in the Analyzetool

270

Design Environment

You may enter one UNIX directory which should include analysed copies of rele
vant signal descriptions. In addition you may activate default signal libraries by
clicking on the little arrows in the signal handling window.

Finally, click on Options/Compiler Options... to pop up the window shown in
Figure 12.33.

Figure 12.33

Setting options and properties for the Analyzetool

To ﬁnd out what the various items in the Options window can do for you, move
the mouse pointer over the item of interest, and press <HELP> on your keyboard.
Note that another window will appear, called the Analyzetool Help window pro
viding you with context-sensitive help.

For instance, the Help message for the ﬁrst entry called Foot tells you: "Select
Foot if you want ID information like name, date, class, designer etc. at the bottom
of each page in the listing ﬁle." Take some time to ﬁnd out about the other proper
ties yourself.

271

Plex-C 1

Testing with the Emulator

This segment presents the APZ emulator in combination with PlexView on UNIX
workstations. You need the necessary dump ﬁle and PlexView database in a
directory to be able to continue with this chapter. This book does not discuss the
generation of such dump ﬁles.

Figure 12.34

Files used in emulator testing with EmuTool and PlexView

To start the emulator test, you only need the following two ﬁles:

*.emudump

software dump ﬁle for the emulator (one ﬁle for all blocks)

*.hi4

extension ﬁle to PlexView database (one ﬁle per block included
in the dump). The ﬁle names will end with xyz, i.e., any combi
nation of three digits and letters representing an encrypted ver
sion of the block ID.

The APZ emulator can load and run several blocks, even several APT subsys
tems, at the same time. The example in this chapter loads only one block called
emutest into the emulator.

Most other ﬁles in the directory shown are Plex-C source ﬁles. In addition, the
EmuDumpGenTool produces this ﬁle during dump generation:

*.emuitm

emulator dump ﬁle for one block (the *.emudump ﬁle is built
using the various *.emuitm ﬁles as input during generation of
the dump.)

The APZ emulator on your UNIX workstation is accessible though the EmuTool.
Drag and drop the icon of the *.emudump ﬁle to the EmuTool icon to start the
application.

272

Design Environment

Figure 12.35

Starting the EmuTool with drag and drop

The main window of the EmuTool appears on your screen. It should resemble the
window in Figure 12.36.

273

Plex-C 1

Figure 12.36

EmuTool main window – initial state

As shown in Figure 12.37, use the emulator command –osx to switch off all trac
ing in the emulator. The emulator runs considerably faster then and issues less
unwanted messages.

274

Design Environment

Figure 12.37

Switching off tracing in EmuTool

Figure 12.38 shows the emulator after tracing has been switched off.

Figure 12.38

EmuTool after tracing has been switched off

Note the status message at the top of the window. (C) indicates that the emulator
is running on job buffer level C. This is the default setting. ‘Monitor block:
EMUTEST’ indicates the current block. If EMUTEST is not the current block,
type B EMUTEST in the lower pane. ‘Trace: 0’ indicates that tracing has been
switched off.

The next step is to start the PlexView program. PlexView is an excellent, useful
and easy tool to browse any type of Plex document. Enter startpv in the emulator
to get the program started.

Do not start PlexView by clicking on its icon in the APS Toolbox, as this would
not set up the useful connection between the emulator and PlexView, but have
both programs as independent, stand-alone tools.

275

Plex-C 1

Figure 12.39

Starting PlexView from the EmuTool

A large window with loads of buttons appears on the screen after some seconds of
waiting.

Browsing Code with PlexView

Figure 12.40 shows PlexView with its demonstration database appearing by
default. Your local PlexView installation may load a different default database.
This does not affect this course, however, and you will load your local sample
database ﬁle next.

276

Design Environment

Figure 12.40

PlexView main window

Now load the plexview database extension ﬁle. Add this ﬁle to the default blocks
which are already shown in your PlexView system. To load the PlexView data
base for block emutest, choose Properties ... from the main pop-up window in
PlexView. See Figure 12.41.

277

Plex-C 1

Figure 12.41

Choosing Properties in the PlexView pop-up window

The Properties window appears on your screen. Click with the right mouse but
ton, the Menu button in SUN-speak, on the Insert button in this window. A pull-
down menu opens; choose Update Directory ... See Figure 12.42.

278

Design Environment

Figure 12.42

The Update Directory ... button in the PlexView Properties window

The Select Update Directory window appears. Use your mouse to select the right
directory containing the PlexView database extension. Then click on the Insert
button and choose Top. See Figure 12.43.

Figure 12.43

Adding an update directory including a PlexView database

In the Properties window, click on the Apply button. Then close this window, it is
no longer needed.

279

Plex-C 1

PlexView now adds one or more ‘local update’ blocks in the main window, at the
beginning of the PlexView block index. See Figure 12.44.

Figure 12.44

Local update block at the beginning of the block index in PlexView

Double-click on the desired block in the block index to load its document survey.

Figure 12.45

Document Survey for block emutest in PlexView

280

Design Environment

There is a lot of useful administrative information in this document, including
product and document numbers, plus an extended signal survey showing all sig
nals sent and received by your software unit.

At the right side of the window, PlexView displays a large number of buttons to
access different parts of the Plex documentation. The Compile Section includes
buttons to browse the parameter list, the base address table, a list of unused regis
ters, DS constants (values of number and string symbols), initial data (set in data
sector), symbol values (numeric representations of symbol variable values), and
send and receive signals. You should try all these buttons now, and look at the
information accessible for each one.

Figure 12.46

Compile section buttons in PlexView

The Program Section buttons provide direct links to various parts of your SPI ﬁle.
For instance, clicking on Program Start takes you to the ﬁrst line of the docu
ment. Clicking on Variable takes you to the ﬁrst variable declaration, and Main
Program displays the program sector of your source code.

Figure 12.47

Program section buttons in PlexView

281

Plex-C 1

Figure 12.48 shows the display of the program start for block emutest. As the
sample block is fairly small, you will not notice much of a difference between
clicking on Program Start, Declare, Variable or Main Program. If you are
browsing a typical ﬁle of several thousand Plex lines, you will be grateful for
these buttons, however.

Figure 12.48

Browsing the beginning of the source program after clicking on Program Start

Clicking on Main Program will display the beginning of the program sector, as
Figure 12.49 shows. If you moved the cursor to a different location in the pro
gram sector, you would return to this position after clicking on Main Program.

282

Design Environment

Figure 12.49

Browsing the Plex program sector after clicking on Main Program

Another highly useful feature of PlexView is its advanced, rapid search function.
To search for a string, simply enter the characters and you will notice the cursor
moving to the next available text matching your input. Then press <RETURN> to
repeat your search.

See Figure 12.50 for an example. Note that as you type, the search string is shown
in the bottom left corner of the PlexView main window.

283

Plex-C 1

Figure 12.50

Searching for string “BEGI” in PlexView

In addition, you may also use the Search window which allows you to search for
GOTO labels, subroutine names, strings, and signal and variable names. The
search history will help you to get back to any search string that you have entered
before.

Figure 12.51

Starting the PlexView Search function from the pop-up menu

284

Design Environment

Browse the source program ﬁle in Plex or in ASA mode. In mixed mode, you
would see the assembler lines right below the corresponding Plex commands.
Use the radio buttons to toggle between the settings.

Figure 12.52

Changing to mixed mode (ASA and Plex) with radio buttons

Figure 12.53 shows software unit emutest in mixed mode. For each Plex line, the
corresponding ASA statements follow.

Note that the assembler code is always correct. The assignment between Plex
statement and ASA instructions is not. Unfortunately, the compiler sometimes
makes incorrect assignments between Plex and ASA lines. So, if in doubt, do not
trust this feature.

285

Plex-C 1

Figure 12.53

Browsing a source program in PlexView’s mixed mode (Plex and ASA)

PlexView and EmuTool cooperate with each other. There are three buttons in the
top right corner of the PlexView window controlling the execution of the pro
gram. Note that two of these buttons are passive (shown in grey), as long as the
program is not halted at a breakpoint. See Figure 12.54.

286

Design Environment

Figure 12.54

Emulator control buttons in PlexView

Figure 12.55 shows the setting of an emulator breakpoint using the PlexView
Stop button. Click on the same button to remove a breakpoint. Note that you can
set breakpoints in ASA statements only. If PlexView is in Plex mode, the break
point will be shown at the nearest Plex statement.

When the breakpoint has been set, a STOP sign appears at the beginning of the
ASA line. In addition, EmuTool issues a message indicating the instruction
address of the ASA statement with the breakpoint.

At the breakpoint, the program execution (or emulation) stops, and you may
inspect the values of variables and the state of registers.

Figure 12.55

Setting an emulator breakpoint from PlexView (on ASA instruction JTR AR0, 2)

APZ Emulator Commands in EmuTool

Going back to the EmuTool it is time to learn some basic emulator commands.
The commands are used for sending signals, inspecting variable values and
checking register states.

287

Plex-C 1

In the following picture, the ‘s’ command is shown. It is used for signal sending.
The syntax is “ s <signalname> <signal data> ”. The current CP SW unit receives
the signal and executes the following ENTER-to-EXIT routine. In Figure 12.56,
the designer sent signal START with three signal data, 1, 42 and 2. Tthe upper
pane or section of the EmuTool window repeats the command and the signal
information.

In the example, the breakpoint set in Figure 12.55 is still active. The execution
stops at this breakpoint, at instruction address H’ 002E. Now the designer can
check variables and registers if desired.

Figure 12.56

Starting the execution of block emutest by sending signal START with data 1, 42, and 2

Inspecting Variables

Emulator command ‘v’ is used to inspect the value of DS variables. Note that it is
impossible to inspect temporary variables or pointers with the ‘v’ command.

In the following example, the value of common stored variable CINDNUM is
checked. The emulator replies with the hexadecimal and the decimal value (8) of
that variable.

The variable CINDNUM was initialised in the data sector, and apparently its
value has not been changed yet.

288

Design Environment

Figure 12.57

Inspecting common variable CINDNUM at breakpoint H’ 002E

Arrays or indexed variables may also be inspected with command ‘v’.

PlexView allows to inspect variable values, too. Double-click on the name of any
DS variable in the PlexView window. The variable value will be displayed in the
EmuTool window. Furthermore, the emupvserver window will appear listing the
names of the current variable and block, as well as the type of the variable. See
Figure 12.58.

289

Plex-C 1

Figure 12.58

Inspecting common variable CINDNUM by double-clicking on the variable name
in PlexView

One-dimensional arrays may be inspected with emulator command
‘v <array> (index)’ as you might expect. For instance, ‘v carray (5)’ would tell
you the value of the sixth element in indexed variable carray. Two-dimensional
arrays have to be inspected with ‘v <second index> : <array> (ﬁrst index)’ which
is a bit unusual. For instance ‘v 6:carray (4)’ would tell you the value of array ele
ment carray (4, 6).

Checking individual variables is quite simple too. Use the following syntax:
‘v <pointer> : <indvar>’. For instance, command ‘v 5:state’ would return the
value of variable state in the sixth record of the ﬁle.

You may also inspect the values for several records at the same time. The com
mand syntax is quite easy. Figure 12.59 shows an example where variable state is
printed for records 1, 2, and 3 with command ‘v 1-3:state’.

The symbol variable state has been set to 1 in all records. This is the initial setting
made in the data sector. Use the button Symbol Values in PlexView to ﬁnd out
about the correspondence between symbol values for symbol variables and their
numeric representations. Unfortunately, the emulator does not display symbol
values.

290

Design Environment

Figure 12.59

Inspecting individual variable STATE in records 1, 2, and 3 at breakpoint
H’002E

To display individual variables for all existing records, simply type
‘v <individual variable>’. For instance, ‘v state’ will display the value of individ
ual variable state in all declared records.

In a quite similar way, use command ‘v 1:*’ to inspect all individual variables in
record 1.

Temporary variables and pointers cannot be checked directly. Instead, it is nec
essary to look at the different registers, which may be a bit difﬁcult at the begin
ning. In the following example, let us look at our signal data and whether they
were stored in the right registers. Remember that the signal data are consecutively
stored in registers PR0, DR0, DR1, DR2, ..., DR 23. Since we sent three data with
the signal START, we should inspect registers PR0, DR0 and DR1.

291

Plex-C 1

The syntax for checking register states is ‘r <register>’. According to the com
mands in Figure 12.60, the data 1, 42, and 2 for signal START have been assigned
to the right registers.

To display the values of all 64 registers at the current job handling level (THL,
CL, or DL), use command ‘r’ without any parameters.

Figure 12.60

Checking the contents of registers PR0, DR0, and DR1

After interrupting the program execution at a breakpoint, click on the Emulator
buttons in PlexView to continue the execution of the program.

Figure 12.61 shows how to run the next two assembler statements after break
point H’ 002E.

292

Design Environment

Figure 12.61

Step: executing the next assembler instruction

If PlexView is in mixed or ASA mode, clicking on the Step button the current line
moves down to the following assembler instruction, see Figure 12.62. In the
example, the current line is now at line #0037.

293

Plex-C 1

Figure 12.62

PlexView moved the current line to instruction address H’ 0037 after one emulator step

294

Design Environment

Figure 12.63

Emulator control buttons in PlexView

The Play button

continues the program execution to the EXIT

statement or the next breakpoint in the program. It has the same effect as the cont
command in the emulator.

The Slow Motion button

executes the next line in the

program. If PlexView is in Plex mode, the emulator carries out the next Plex
statement. If PlexView is in mixed or ASA mode, the emulator carries out the next
assembler statement.

Find out yourself about the other features of the EmuTool/PlexView connection.
Both tools have very useful help functions. Have fun!

Figure 12.64 shows how to ﬁnd help for the EmuTool as well as the syntax and
application of the various emulator commands.

295

Plex-C 1

Figure 12.64

Getting help on emulator commands in the EmuTool

296

Appendix

Appendix A

Addressing: Multiple and RP-CP Signals

299

Appendix B

File-Oriented Input and Output

309

Appendix C

Exercises

321

Appendix D

Index

359

297

Plex-C 1

298

Appendix A Addressing: Multiple and

RP-CP Signals

Introduction

Extending the addressing principles for unique signals discussed in Chapter 6,
Block Interaction, this appendix contains a detailed example of the addressing
method used when sending a multiple signal from one SW unit to another.

Furthermore, part 2 of this appendix now brieﬂy presents the addressing concept
for RP-CP signals.

Multiple Signal Sending

The addressing in multiple signal sending is slightly more complex than for
unique signal sending, as the local signal number (LSN) cannot be determined
from the global signal number. For a full discussion of unique signal sending, see
Chapter 6, Block Interaction (page 129).

Multiple signals are handled in a different way, since one and the same signal can
be sent to different blocks. The receiving block is addressed during program exe
cution, and which block the signal will be sent to depends mainly on the trafﬁc
case.

The block reference of the receiving block is speciﬁed in the signal sending state
ment (SIGNAL signal REFERENCE block reference ...). The APZ translates the
block reference into the block number of the receiving block (BN–R). A special
processor register in the register memory contains the BN-R. Two parameters
determine the actual entry point of a multiple signal:

•

global signal number (GSN) and

•

block number of the receiving block (BN–R).

If both of these values were used to address a table, this table would be extremely
large, as the GSN has a value between 1 and 65535 and the BN-R a value
between 1 and 4096 (64k x 4k = 256 M words). To avoid wasting so much mem
ory, the GSN and the BN–R are combined with an exclusive-or (XOR) operation,
resulting in the address to the global signal distribution table for multiple signals
(GSDT-M). The XOR operation is explained in Figure A.1.

In some cases, of course, there will be a collision, as the combination of different
BN–R’s and GSN’s may lead to the same XOR result. See Example 99.

299

Plex-C 1

11010

XOR 10110

= 01100

#1A XOR #16 = #0C

26 XOR 22 = 12

Decimal Notation

Binary Notation

Hexadecimal Notation

XOR Value Table

Figure A.1

The exclusive-or operation (XOR): value table and example

The value received by the XOR operation from GSN and BN–R is called the hash
index for the GSDT-M.

Example 99

The example shows how different BN-R and GSN can lead to the same value if
combined using the XOR operation.

BN–R

GSN

BN–R "XOR" GSN

# 06

# 12

# 14

# 12

# 06

# 14

# 18

# 0C

# 14

etc.

Figure A.2

Combining BN–R and GSN using XOR

To handle such collisions, the GSDT-M needs a collision table for all cases where
different BN–R and GSN values result in the same XOR value.

Global Signal Distribution Table for Multiple Signals

The GSDT-M contains block numbers for the receiving blocks and local signal
numbers for multiple signals. The table is addressed with the hash index, that
is, hash index = BN-R XOR GSN.

If the hash index is the same for different receiving blocks, the GSDT-M stores
the address to a collision table, the collision table start address (CTSA). In the
collision table, the BN-R is used to ﬁnd the right LSN. Please study Figure A.3.

300

Addressing: Multiple and RP-CP Signals

Hash
Index = 0

.
.
.
.

BN-R

CTI 1

CTI n

LSN

.
.
.
.

BN-R

LSN *

.
.
.
.

65535

CTSA

Hash Index

Collision Table

GSDT-M

Hash Index = BN-R XOR GSN

GSN

Global Signal Number

BN-R

Block Number Receiving

LSN

Local Signal Number

CTSA

Collision Table Start Address

CTI

Collision Table Index

LSN *: Note that there is no LSN at this position,
if the hash index is ambiguous

Figure A.3

The global signal distribution and collision tables for multiple signals in the APZ

The following text describes the sequence of events when block A sends a multi
ple signal to block B. The main difference from unique signal sending is that the
GSDT-M has one extra word per entry storing the address to the collision table.

301

212

Plex-C 1

Note that only some 20% of the entries in the GSDT-M actually have a collision
table.

Figure A.4 shows the situation for the APZ 212 processor, although the way of
addressing is the same for the APZ 211 processor. The main differences concern
the size and order of the data words.

SSIB is the ASA instruction “Send Signal Indirect Buffered”. SSIB sends single,
multiple and buffered signals.

All signal sending instructions in the assembler code have the
parameter signal sending pointer (SSP). SSP points to the corre
sponding entry in the SST.

The SSP is added to the PSA to obtain the GSN (PSA + SSP

→

GSN).

The APZ translates the block reference of the receiving block in the
signal sending statement to the BN-R and stores it in a processor
register. The GSN and the BN–R are now combined using an XOR
operation. The result is used as the address or hash index to the
GSDT-M.

The GSDT-M provides the LSN. In case of collisions (several com
binations of GSN XOR BN–R give the same result), the CTSA
points to the start address of the collision table.

If BN–R in the GSDT-M does not match the BN–R fetched from the
signal sending statement, the addressing routine jumps to the colli
sion table. In this table, the BN–R is the search key to ﬁnd the corre
sponding LSN.

The BN–R also addresses the reference table (RT), ﬁnding the PSA
for the receiving block.

The PSA denotes the starting point for ﬁnding the correct program
sequence in the receiving block B.

The LSN for the signal is subtracted from the PSA to ﬁnd the corre
sponding entry in the SDT. This table contains the IA marking the
start of the program sequence (PSA – LSN

→

IA).

The relative instruction address (IA) points to the signal reception
statement (ENTER ...) in the code. The program starts executing at
this statement.

302

Addressing: Multiple and RP-CP Signals

BSA

PSA

BN-R= —

LSN= —

.
.
.
.

SDT

Program Code

SSIB, ssp = 12

SST

GSN = # C

SDT

SST

GSN = # C

ENTER Signal

PSA

Block A

(entry for Block B)

GSDT - M

Block B

(BN = # 18)

PSA

SSP

# 35

.
.

LSN

.
.

Program Code

BN-R XOR

GSN = # 14

# 14

Hash

CTSA = ctn

BN-R = # 18

BN-R = # 12

LSN = # 35

LSN = # 23

. . . . . .

Spare

64k

ctn

0
.

# 18

LSN=# 35

PSA

BN-R=# 18

Attributes

Reference Table

Index

Hash Index

Collision Table

BN-R = #18 (from register)

Figure A.4

Addressing method for a multiple signal in the APZ 212

303

Plex-C 1

Addressing for RP-CP signals

Addressing RP-CP signals is slightly more complicated than regular CP-CP sig
nals. The following text gives a simpliﬁed description of sending a signal from an
RP to a CP software unit.

RP SW unit

CP SW unit

Marshal document

for regional software

RPH

Regional Processor Handler

RP no.

Central RP Table

SGN

job buffer

SGN

RP no.

Figure A.5

Sending a signal from RP to CP software (simpliﬁed)

In Figure A.5 the following abbreviations appear:

304

Addressing: Multiple and RP-CP Signals

block number

central processor

regional processor

RP no.

regional processor number

SGN

signal group number

local regional signal number

software

A marshal document is used to compile the regional software units. Program pro
duction engineers write this document, which contains administrative informa
tion for generating object code. The marshal includes numbers for all regional
signals and deﬁnitions of signal group names. The same type of document was
used before when compiling central software units, but the rationalised software
production (RSP) concept replaced this marshal document for CP SW units.

The signal group name is unique for a block. It deﬁnes the signal group number
used in addressing the signal distribution table in the CP SW unit. In the RP SW
marshal document, all signals are listed which are included in a signal group.

In Figure A.5, the marshal document deﬁnes the local regional signal number.
The RP handler provides the number of the RP.

The signal including its local regional signal number, its RP number, and all data
words are stored in one of the job buffers JBA, JBB, JBC or JBD.

The central RP table stores the signal group number and block number for all RP
CP signals identiﬁed by their local regional signal number.

The block number determines the CP SW unit’s program start address (PSA) in
the reference store.

The signal group number and the local regional signal number determine the sig-
nal’s entry point in the SDT of the CP SW unit. See Figure A.6.

305

Plex-C 1

Program Store

CP SW Unit

SGN

LSN = SN + SGN

PSA – LSN

→

SST

Code

Correction

Area

CP-CP signals

RP-CP signals

221

220
.

.
201

200

SDT

199

PSA

Figure A.6

RP-CP signals in the SDT

Figure A.6 contains the following abbreviations:

central processor

instruction address

LSN

(absolute) local signal number

PSA

program start address

regional processor

RP no.

regional processor number

SDT

signal distribution table

SGN

signal group number

local regional signal number

SST

signal sending table

306

Addressing: Multiple and RP-CP Signals

The SDT stores all RP-CP signals in groups. During program production, the sig
nal group number (SGN) points to the ﬁrst idle position after the CP-CP signals
have been inserted in the SDT. After the RP-CP signals have been added, the
SGN points to the ﬁrst RP-CP signal in the SDT. The complete local signal
number (LSN) is calculated by adding the regional local signal number (SN) and
the SGN.

The LSN then points to the entry point for the RP-CP signal in the SDT. Among
other data, the SDT shows the instruction address (IA) for the signal reception
statement, the absolute address pointing to the ENTER statement of the signal.

307

Plex-C 1

308

Appendix B File-Oriented Input and Output

File-oriented I/O statements transfer larger amounts of data.

•

From a user block to a ﬁle on an I/O device

•

From a ﬁle on an I/O device to a user block

I/O devices for ﬁle-oriented input and output include magnetic tapes, CD-ROMs,
hard, or ﬂexible disks. See Figure B.1.

HD = Hard Disk

CP = Central Processor
SP = Support Processor

FD = Flexible Disk
MT = Magnetic Tape
CD = CD-ROM

Figure B.1

Different types of ﬁle-oriented I/O devices

It is not necessary to know which I/O device stores a ﬁle. Before writing or read
ing a ﬁle, an operator gives commands, including the name of the ﬁle. The I/O
system then ﬁnds the I/O device containing the ﬁle.

309

Plex-C 1

Read

User

Release File

I/O System

Write

Program Store

Block

Seize File

Line Buffer

Analysis Buffer

Figure B.2

The four ﬁle-oriented input output statements

Note that these input-output ﬁles have nothing in common with the ﬁles of
records discussed earlier in this book.

Figure B.2 shows four statements for ﬁle-oriented input and output.

When seizing an I/O ﬁle, name the ﬁle and whether writing or reading is
required. A seized I/O ﬁle cannot be read and written at the same time.

The user blocks read and write data from a dynamic buffer.

There is one major difference between alphanumeric and ﬁle-oriented input/out-
put. File-oriented data is not stored in the analysis/line buffer. The data just sim
ply passes through the seized buffer. Hence, there is no need to insert or fetch
data from the analysis/line buffer.

A ﬁle consists of one or more data blocks. All writing and reading of ﬁles uses
these data blocks. For example, the WRITE statement transfers one data block
from the user block to the ﬁle.

A data block has a minimum of 18 and a maximum of 2048 eight-bit characters,
not necessarily ISO coded.

The I/O system must know all ﬁle names before seizing them. Operator com
mands deﬁne such ﬁle names at start-up of the exchange.

File deﬁnition includes specifying whether the ﬁle is divided into subﬁles. Divi
sion of a ﬁle into subﬁles is a way to structure the information in the ﬁle into parts
(subﬁles), which can be separately read or written from an I/O device. See Figure
B.3.

310

File-Oriented Input and Output

CHARG.A1

CHARG.A2

CHARG.A3

CHARG

Figure B.3

Input output ﬁle CHARG divided into three subﬁles

Seizure of File

Before writing or reading a ﬁle, seize the I/O device containing the ﬁle using the
SEIZE FILE statement, see Figure B.4.

User

I/O System

Program Store

Block

Line Buffer

Analysis Buffer

Seize

Figure B.4

Seizing a ﬁle for output

The I/O system assigns a free analysis/line buffer to the I/O device, or more cor
rectly the I/O ﬁle.

311

Plex-C 1

SEIZE FILE ﬁle name

, CODE IS io-code

;

ABRANCH IS label

, POINTER IS pointer

FOR

ISO

OUTPUT

INPUT

io-individual ,

. subﬁle

, BUFFER IS buffer

( gen )

BINARY

ID IS

Figure B.5

Syntax for File Seizure

Please see the following box for syntax explanations.

ﬁle name = a string variable, local or global string symbol containing the name of
the ﬁle to be seized. (Maximum 12 characters). File name can also be an explicit
string. The ﬁle name must have been deﬁned in the I/O system.

subﬁle = a string variable, local or global string symbol containing the name of
the subﬁle to be seized. (Maximum 12 characters). Can also be an explicit string.
The subﬁle is not deﬁned in the I/O system.

gen = a string variable, local or global string symbol containing the name of the
generation to be seized. (Maximum 12 characters). Can also be an explicit string.
The generation concerns the subﬁle and is not deﬁned in the I/O system.

io-individual = a 16 bit ﬁeld variable which, after execution of the statement,
contains the number of the seized analysis/line buffer. The number must always
be used in the ID ﬁeld of the READ, WRITE and RELEASE statements.

label = program label to which a jump is made if seizure fails.

io-code = a structured 16 bit variable which, after execution of the statement,
contains an answer code from the I/O system.

pointer = any pointer in the program to be saved. Pointers and temporary vari
ables lose their values when the SEIZE FILE statement is executed.

buffer = a buffer variable, possibly in a record. If this ﬁeld is used, the I/O system
will use dual buffers. One example of this is that while the I/O system writes out
the contents of the buffer variable, data is assigned the other buffer variable. The
use of dual buffers makes the data transfer more efﬁcient.

The keyword ISO indicates ﬁles using CCITT no. 5 character coding. BINARY
indicates that the data is not in ISO code.

If the I/O device is busy, the device is seized as soon as it becomes idle.

312

File-Oriented Input and Output

Example 100

The variable CPEB contains the name of the ﬁle. This example seizes the ﬁle for
the output of data in ISO code.

PROGRAM; PLEX;

....

SEIZE FILE CPEB FOR ISO OUTPUT,

ID IS CIOBUFFER,

ABRANCH IS SEIZEERROR600,

CODE IS CIOCODE;

Figure B.6

Seizure of File

After execution of the statement, the variable CIOBUFFER contains the number
of the seized analysis/line buffer.

If the seizure fails, the program jumps to label SEIZEERROR600. The I/O sys
tem uses variable CIOCODE for storing the answer code.

To transfer data from an I/O device to the user block, use the same SEIZE state
ment, but substitute OUTPUT with INPUT.

Example 101

This example seizes a ﬁle for input. BINARY indicates that the ﬁle is not coded
in ISO code.

PROGRAM; PLEX;

....

SEIZE FILE CPEB FOR BINARY INPUT,

ID IS CIOBUFFER,

ABRANCH IS SEIZEERROR600,

CODE IS CIOCODE;

Figure B.7

Seizure of File

Example 102

This example seizes a ﬁle divided into subﬁles for read access.

313

Plex-C 1

DECLARE;

....

STRING VARIABLE CPEB 15 DS;

STRING VARIABLE CPART1 15 DS;

....

END DECLARE;

PROGRAM; PLEX;

....

CPEB = "DUMPFILE";

CPART1 = "SUB1";

....

SEIZE FILE CPEB.CPART1 FOR ISO INPUT,

ID IS CIOBUFFER,

ABRANCH IS SEIZEERROR600,

CODE IS CIOCODE;

....

END PROGRAM;

Figure B.8

Seizure of Subﬁle

The SEIZE statement results in a search for subﬁle SUB1 in ﬁle DUMPFILE by
the I/O system.

The statement seizes the subﬁle SUB1. It is now possible to read data from the
subﬁle into a buffer in the user block.

Example 103

Here is a real-life example. The back-up ﬁle RELFSW0 is kept on hard disk in
the IOG-11 (input output system). This ﬁle divides into six subﬁles and contains
a back-up copy of the SW in the exchange.

The subﬁles are:

RELFSW0.R0

Administration data.

RELFSW0.R1

Charging data.

RELFSW0.R2

— " —

RELFSW0.R3

Exchange data, in particular variables marked RELOAD, and
global number symbols.

RELFSW0.R4

— " —

RELFSW0.R5

Program and reference stores.

Writing a Block to a File

Programs use the WRITE statement to transfer data, for example, charging data,
from the CP SW unit to a ﬁle on the I/O device.

314

File-Oriented Input and Output

Each WRITE statement transfers one data block. Sometimes programs need sev
eral WRITE statements to transfer all the data.

Before executing the WRITE statement, programs have to seize the ﬁle for OUT
PUT. The CP SW unit has to place the data block to write in a buffer variable
before the writing.

io-individual ,

, CHANUM IS number

, CODE IS io-code

;

ABRANCH IS label

, POINTER IS pointer

WRITE BLOCK BUFFER buffer , ID IS

Figure B.9

Syntax for Writing a File

Please see the following box for syntax explanations.

buffer = Buffer variable from which the data is fetched.

io-individual = a 16 bit ﬁeld variable which contains the number of the seized
analysis/line buffer. The number was assigned in an earlier SEIZE statement.

label = program label to which a jump is made if something fails.

io-code = a structured 16 bit variable which, after execution of the statement,
contains an answer code from the I/O system.

number = variable containing the number of 8-bit characters in the buffer.

pointer = any pointer in the program to be saved. Pointers and temporary vari
ables lose their values when the WRITE statement is executed.

Example 104

This example shows the writing of a ﬁle on an I/O-device.

PROGRAM; PLEX;

....

WRITE BLOCK BUFFER COUTPUTVAR,

ID IS CIOID,

ABRANCH IS WRITEERROR130,

CODE IS CFAULTCODE,

CHANUM IS CBLOCKSIZE;

Figure B.10

Writing of File

315

Plex-C 1

This statement writes the contents of the buffer variable COUTPUTVAR into the
seized I/O ﬁle. In earlier statements, the buffer variable has, of course, been
assigned values.

The variable CBLOCKSIZE contains the number of characters or the block size
to be written. The number may vary between 18 and 2048 (8-bit) characters in
one block.

Reading from a File into a Block

READ transfers one data block from an I/O ﬁle to a dynamically allocated buffer
in the user block. Before reading the data, seize the ﬁle for INPUT.

io-individual ,

, CHANUM IS number

, CODE IS io-code

;

ABRANCH IS label

, POINTER IS pointer

READ TO BLOCK BUFFER buffer , ID IS

Figure B.11

Syntax for Reading a File

buffer = buffer variable where the transferred data block is stored.

io-individual = a 16 bit variable which contains the number of the seized analy-
sis/line buffer. The number has been assigned in an earlier SEIZE statement.

label = program label to which a jump is made if something fails.

io-code = a structured 16 bit variable which, after execution of the statement,
contains an answer code from the I/O system.

number = variable which, after execution of the statement, contains the number
of 8-bit characters in the buffer variable.

pointer = any pointer in the program to be saved. Pointers and temporary vari
ables lose their values when the READ statement is executed.

Note that a READ statement reads the entire data block.

Example 105

This example shows the reading of a ﬁle.

316

File-Oriented Input and Output

PROGRAM; PLEX;

....

SEIZE FILE CPEB FOR ISO INPUT,

ID IS CIOID,

ABRANCH IS SEIZEERROR130,

CODE IS CIOCODE;

....

READ TO BLOCK BUFFER CINBUF,

ID IS CIOID,

ABRANCH IS READERROR140,

CODE IS CIOCODE,

CHANUM IS CNUMOFCHAR;

Figure B.12

Reading a File

The ﬁrst statement results in a seizure of the I/O device containing the ﬁle.

After execution of the statements, the following has happened:

•

A data block has been transferred from the seized ﬁle to the buffer variable
CINBUF.

•

If the read fails, a jump is made to label READERROR140 and the reason is
indicated in the variable CIOCODE.

•

Variable CNUMOFCHAR contains the number of characters in the buffer
variable, i.e., the number of characters sent with the READ statement.

•

The variable CIOCODE contains the answer code from the I/O system. Bit
11 in the variable indicates if it is the end of ﬁle, i.e., no more data blocks to
read. If there are more blocks to read, we must execute statements emptying
the buffer variable and then execute a new READ statement.

Reading data block by data block continues until the ﬁle has been read com
pletely.

Release of File

After writing or reading a ﬁle, the program has to release the ﬁle again, using the
RELEASE FILE statement.

317

Plex-C 1

io-individual

label

io-code
contains an answer code from the I/O system.

the additional dual

FILE.

pointer

RELEASE FILE

, CODE IS io-code

;

, ABRANCH IS label

, POINTER IS pointer

io-individual

= a 16 bit variable which contains the number of the analysis/line

buffer to release. The number was assigned in an earlier SEIZE statement.

= program label to which a jump is made in case of an error.

= a structured 16 bit variable, which after execution of the statement,

buffer = buffer variable. After execution of the statement, the variable contains

buffer that was speciﬁed in the SEIZE FILE statement. If the

BUFFER keyword is used in SEIZE FILE, it must also be used in RELEASE

= any pointer in the program to be saved. Pointers and temporary vari

ables are destroyed when the RELEASE statement is executed.

BUFFER IS buffer

ID IS

Figure B.13

Syntax for Release of File

The keywords CODE IS ... , ABRANCH IS ... and POINTER IS ... are only nec
essary, if an additional dual buffer was speciﬁed using the BUFFER IS ... key
word.

In this statement, the program does not have to specify the name of the I/O ﬁle to
be released. It is sufﬁcient to know the number of the analysis/line buffer.

All programs have to release the I/O ﬁle after the data transfer, even if a fault
occurred in the WRITE or READ statement, and the program jumped to the
ABRANCH label.

Overview of File-Oriented I/O statements

This section is a brief summary of all ﬁle-oriented I/O statements, which transfer
data between buffers in the user blocks, and ﬁles in the I/O system.

318

File-Oriented Input and Output

Input Output

Statements

Alphan

umer

ic I/O

File-or

iented I/O

Input

Output

Loc

king

Input

Output

Loc

king

COMMAND

INSERT

SEIZE DEVICE

READ TO ...

WRITE ...

SEIZE FILE

BUSY

WRITE

SEIZE DEVICE FOR

BLOCK BUFFER

RELEASE FILE

FETCH

RELEASE DEVICE

FETCH PARAMETER

CHECK

FIND

READ

Figure B.14

Overview of all I/O statements

I/O statements are either alphanumeric or ﬁle-oriented statements. File-oriented
statements may be classiﬁed as input, output, and locking statements. There are
two statements for locking and unlocking a ﬁle called SEIZE FILE and
RELEASE FILE. They guarantee exclusive access to a ﬁle for the I/O handling
program.

There is one input and one output ﬁle-oriented I/O statement. These are called
READ TO BLOCK BUFFER, and WRITE BLOCK BUFFER.

319

Plex-C 1

Chapter Summary

From this appendix chapter remember this point:

•

ﬁle-oriented I/O statements are used when large quantities of data have to be
transferred, for example, dumping of charging data.

References

Descriptions on the Use of Dynamic Buffers,
XT/UD 82:064, Rev. A, Ericsson Telecom AB, ETX/TX, 1982

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 ﬁnd this document.

320

Appendix C Exercises

Plex-C 1 Programming: Declare Sector

Exercise 3.1

The following three pages contain a sample Plex-C document with a sam
ple declare sector. Find all the faults in the declare sector; there are a total
of 15 errors in it!

Do not try to ﬁnd any faults in the layout or in any other parts of this docu
ment.

321

---------

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

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

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

Plex-C 1

DOCUMENT KR2UPROGRAM;

CONTENTS:

1 GENERAL

2 DECLARE

2.1 GLOBAL SYMBOLS

2.2 LOCAL SYMBOLS

2.3 RECORDS AND FILESIZES

2.4 COMMON STORED VARIABLES

2.5 TEMPORARY VARIABLES

2.6 STRUCTURES

3 PROGRAM

4 DATA

1 G E N E R A L

2 D E C L A R E

2.1 GLOBAL SYMBOLS

DECLARE;

GLOBAL NSYMB

BTEXTKR2 (#FFFF),

BTKR2 (65536);

GLOBAL STRING

BLOCKNAME (6);

2.2 LOCAL SYMBOLS

NSYMB

ZALLDEVICESBLOCKED=0,

ZDEVICECONNECTED=7,

ZDEVPEREM=8,

ZEXECUTED=O,

ZFCODE1=1,

ZMANUALBLOCKING=1,

ZMAX=8,

ZMAXDEVICEINEM=7,

ZMAXEMGSIZE=32,

ZNOBLOCK=0,

ZNOTCONNECTEDDEVICE=FFFF,

ZNOTDEFINED=2,

PAGE

! OWN BLOCK TYPE EXTENSION !

! OWN BLOCK TYPE !

! OWN BLOCK IDENTITY !

!ALL DEVICES IN EM BLOCKED!

!ERRORCODE IN SIGNAL!

!NUMBER OF DEVICES IN EM!

!ORDER EXECUTED!

!FAULT CODE!

!MANUAL BLOCKING !

!END OF THE LINKED LIST AND CINDNUM!

!MAX NUMBER OF DEVICES IN EM!

!MAX NUMBER OF EM'S IN ONE EMG!

!NOT BLOCKED!

!MARKING FOR NOT CONNECTED DEVICE!

!NO DEVICE CONNECTED!

322

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

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

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

Exercises

ZSAE500=500,

!SIZE ALTERATION EVENT!

ZSTART=3;

!START CASE!

ZYES=1;

2.3 RECORDS AND FILESIZES

RECORD ADDRESSDATA;

VARIABLE

DEVADDR 32 DS RELOAD;

!RP/CM ADDRESS, SEE STRUCTURE!

END RECORD;

POINTER ADDRP(ADDRESSDATA);

RECORD DEVICEDATA;

VARIABLE

ADMSTATE 4 DS RELOAD;

!EM ADMINISTRATION DATA, SEE

STRUCTURE!

VARIABLE

BLSTATE 4;

!DEVICE BLOCKING REASON, SEE

STRUCTURE!

VARIABLE

CALLBLOCKREF 16 DS;

!CALLING BLOCK REFERENCE!

VARIABLE

CALLIND 16 DS;

!POINTER TO CALLING BLOCK!

VARIABLE

EMGNUMBER 16 DS RELOAD;!EM GROUP NUMBER TO DEVICE!

VARIABLE

EMNUMBER 8 DS RELOAD;

!INTERNAL EM NUMBER TO DEVICE!

VARIABLE

SEIZECNT 8 DS CLEAR;

!NUMBER OF SEIZURES!

SYMBOL VARIABLE STATE = IDLE,BUSY,BLOC 8 DS;

!DEVICE STATE!

VARIABLE

TIMER 16 DS CLEAR;

!TIME SUPERVISION!

END;

2.4 COMMON STORED VARIABLES

VARIABLE

CBLSTATE (8) 3 DS;

!BLSTATE FOR EACH DEVICE IN EM!

VARIABLE

CINDNUMA 16 DS RELOAD; !NUMBER OF ADDRESS DATA!

VARIABLE

CINDNUMD 16 DS RELOAD; !NUMBER OF DEVICES!

VARIABLE

COWNREF 15 DS;

!OWN BLOCK NUMBER!

2.5 TEMPORARY VARIABLES

VARIABLE

TBASEPTR,

!TEMPORARY BASE POINTER!

TBLOCKNO,

!TEMPORARY BLOCKNUMBER!

TBLOCKREF,

!TEMPORARY BLOCK REFERENCE!

TDEVP,

!TEMPORARY DEVICE POINTER!

TFAULTCODE,

!TEMPORARY FAULT CODE!

TGLOBALSTATE,

!TEMPORARY GLOBAL STATE!

TINDEX 8,

!INDEX VARIABLE!

TINDIVIDUAL,

!TEMPORARY INDIVIDUAL!

TOWNBLOCKNUM,

!OWN BLOCK NUMBER!

TPOINTER,

!TEMPORARY POINTER!

TRESULTCODE,

!TEMPORARY RESULT CODE!

TRPCMADDRESS,

!TEMPORARY RP AND CM ADDRESS!

TSIGNALCODE,

!TEMPORARY SIGNAL CODE!

TSTARTPHASE;

!RESTART PHASE !

323

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

Plex-C 1

2.6 STRUCTURES

STRUCTURE ADMSTATE =

1 EMCON

1 +

1 TSCON

1 RCON

1 +

STRUCTURE BLSTATE =

1 MBL 1,

1 BLM 1,

1 BLT 1,

1 BLO 1;

STRUCTURE DEVADDR =

2 RPCM 16,

1 CME 16;

END DECLARE;

PROGRAM; PLEX;

END PROGRAM;

DATA;

END DATA;

END DOCUMENT;

ID KR2UPROGRAM TYPE DOCUMENT;

CLA 19055;

NUM CAA 107 9999;

REV PA4;

DAT 98-07-29;

DES ETX/TK/D ERST;

RES ETX/TK/D;

APP ETX/TK/D;

END ID;

!EM ADMINISTRATION DATA!

!ZERO IF CONNECTED TO EM!

!ZERO IF CONNECTED TO TIME SWITCH!

!ZERO IF CONNECTED TO ROUTE!

!DEVICE BLOCKING REASON!

!ONE IF DEVICE MANUALLY BLOCKED!

!ONE IF EM BLOCKED!

!ONE IF DEVICE TEST BLOCKED!

!ONE IF EXTERNALLY AUTOMATICALLY BLOCKED!

!RP/CM ADDRESS!

!RP AND CM ADDRESS!

!EXTENDED CM ADDRESS!

324

Exercises

Plex-C 1 Programming: Using the Analyzetool

Exercise 3.2

This exercise introduces the Analyzetool. Please analyse the program
printed in the previous exercise trying to remove all faults detected by the
Analyzetool. The document contains executable statements in the declare
sector only.

Ask your teacher for the ﬁle edeclare.program. Copy it into your own ﬁle
tree. If you are using the File Manager, double-click on the icon of this ﬁle
to start the Analyzetool. Otherwise you may get the same result by enter
ing the UNIX shell command "analyzetool edeclare.program &" in any
shell tool window.

Try to correct all errors found, and analyse the program again until it is
syntactically correct.

325

Plex-C 1

Plex-C 1 Programming: Declare Sector

Insert the following declarations into the SPI ﬁle used in Exercise 3.2.
Analyse the code and correct any syntax faults.

Exercise 3.3 a

Declare a ﬁeld variable, CNUMBER. The variable should be used to store
numbers between 0 and 60000.

Declare another variable, TLOOPCOUNTER, able to store values up to
100. The variable is used as a counter in an iteration statement.

Exercise 3.3 b

A variable CDEVADDR (16 bits) is broken down into the subvariables
RPADR and EMADR. RPADR uses the 10 least signiﬁcant bits (bits 0 to
9) and EMADR uses the 4 most signiﬁcant bits (bits 12 to 15) of CDE
VADDR. Declare the variable and its structure.

Exercise 3.3 c

A certain telephony device is either idle, blocked or busy. Declare a varia
ble CSTATE representing this in the best possible way.

Exercise 3.3 d

Declare a string variable CANSWER which can be used to store one of the
following strings: "CONGESTION”, “ORDERED”, or "EXECUTED”.
Draw a picture showing how the string "CONGESTION" is stored in the
variable CANSWER.

Exercise 3.3 e

Declare a variable, CHUGE able to store values up to 100000 in all types
of target processors. Then declare a variable CMAXNUMBER using all
bits of the target processor’s registers.

Exercise 3.3 f

Declare a constant used to check the number of loops in a program. Call
the constant ZNUMBEROFCHECKS and set it equal to 4.

326