6100 ADCCP Programming Manual

Transkript

Networking and Data Communications Library
6100 ADCCP
Programming
Manual
Product Version
Release ID
Edition Print Date
Part Number
Abstract
CP6100 C30/D10
C30.09/D10.00
January 1993
069225
This manual describes the 6100 ADCCP and X.21 protocols and contains
information needed to write applications that use the ADCCP or X.21 protocol
modules. This manual is intended for application programmers.
Tandem Computers Incorporated
Document History
Edition
Part Number
Product Version
Release ID
Print Date
First Edition
Update 1
Second Edition
82411
82227
069225
CP6100 B20
CP6100 B20
CP6100 C30/D10
N/A
N/A
C30.09/D10.00
March 1985
October 1985
January 1993
New editions incorporate any updates issued since the previous edition.
Copyright
Export Statement
Copyright © 1993 by Tandem Computers Incorporated. All rights reserved. No part of this document may be
reproduced in any form, including photocopying or translation to another language, without the prior written
consent of Tandem Computers Incorporated. Printed in the United States of America.
Export of the information contained in this manual may require authorization from the U. S. Department of
Commerce.
Warning
This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to
Part 15 of the FCC Rules. The limits are designed to provide reasonable protection against harmful
interference when the equipment is operated in a commercial environment. This equipment generates, uses,
and radiates radio frequency energy, and if not installed and used in accordance with the maintenance manual,
may cause harmful interference to radio communications. Operation of this equipment in a residential area is
likely to cause harmful interference in which case the user will be required to correct the interference at his/her
own expense. Shielded cable/connector assemblies must be used to meet radiated emission limits.
Examples
Examples and sample programs are for illustration only and may not be suited for your particular purpose.
Tandem does not warrant, guarantee, or make any representations regarding the use or the results of the use
of any examples or sample programs in any documentation. You should verify the applicability of any example
or sample program before placing the software into productive use.
Ordering Information
If you would like manual ordering information, contact the following:
Domestic U.S. Customers—Call 1-800-243-6886.
International Customers—Contact your local sales representative.
Please Comment
If you have questions or problems concerning the content of this document, please use the Reader Comment
Card located in the back of this manual.
New and Changed Information
This is the second edition of the 6100 ADCCP Programming Manual. It includes
technical changes and quality revisions to the first edition of this manual.
Technical Changes to This edition describes changes to the configuration block and the two new 6100
the Manual ADCCP features they make possible :
Alternate polling
ADCCP-to-Token-Ring communication
Quality Changes to the The format and style of the first edition have been changed to conform to the current
Manual format and style of Tandem technical publications. Also, the information presented in
first edition has been reorganized. The major organizational changes in the second
edition are:
Section 4, “Writing Applications that Use ADCCP,” now includes information on
Guardian file-system procedures that the programmer may need when writing an
application. This section also includes TAL and C programming examples.
Section 6, “Requests and Responses,” describes the requests and responses that an
application uses to communicate with the ADCCP protocol module. In the first
edition, the requests and responses were part of the section “Writing Application
that Use ADCCP.” Also, the ADCCP requests and responses are now listed by
function code.
Appendix C provides an example of a short C language program that makes a SET
CONFIGURATION request to the protocol module.
Appendix D of the first edition, which described ADCCP/X21, has become two
sections: Section 3, “ADCCP/X21 Protocol Module” and Section 5, “Writing
Applications that Use ADCCP/X21.” The requests and responses for
ADCCP/X21 are included in Section 6 of the second edition.
A glossary has been added and the index is more detailed.
069225 Tandem Computers Incorporated
iii
New and Changed Information
iv
Contents
About This Manual xiii
Notation Conventions
Section 1
xv
Introduction to 6100 ADCCP
Features of the 6100 ADCCP Product
1-1
6100 ADCCP Concepts and Context 1-4
Station Types 1-4
Line Control Modes 1-6
Normal Response Mode (NRM) 1-6
Asynchronous Response Mode (ARM) 1-7
Asynchronous Balanced Mode (ABM) 1-7
Extended Mode 1-8
Frame Formats 1-8
Flag Sequence 1-9
Address Field 1-9
Control Field 1-11
Extended Control 1-13
IBM Extended Control (IEC) 1-13
Information Frame Control Field 1-13
Supervisory Frame Control Field 1-14
Unnumbered Frame Control Field 1-15
Information Field 1-17
Frame Check Sequence Field 1-17
Abort Sequence 1-17
Line-Configuration Options 1-18
Section 2
ADCCP Link and Station Management
Protocol Task Architecture
2-1
Link States and Transitions 2-4
DISCÎDLE State 2-5
DISC^WAIT State 2-5
READYÎDLE State 2-6
XMIT State 2-6
Station States and Transitions 2-6
Logically Disconnected State (LDS) 2-8
Mode Setting State 2-10
Initialization State (IS) 2-10
Information Transfer State (ITS ) 2-10
v
Contents
Polling 2-12
Standard Polling 2-12
Alternate Polling 2-14
ADCCP to Token Ring Communication
Station and Data Capacity on Links
Section 3
2-15
2-16
ADCCP/X21 Protocol Module
Features of ADCCP/X21
3-1
ADCCP/X21 Protocol Task Architecture
ADCCP Protocol Task 3-2
Call-Control Task 3-3
X.21 Driver 3-3
3-2
Line Configuration Options 3-3
ADCCP Line Configuration Options 3-3
X.21 Line Configuration Options 3-3
ACCEPT CHARGES 3-4
CIRCUIT-SWITCHED 3-4
CPS ACTION TABLE 3-4
NOT READY STATE 3-6
RETRY INTERVAL 3-6
RETRY MAXIMUM 3-6
DTE Time Limits 3-6
Link States and Transitions 3-7
Link States for Circuit-Switched Lines 3-8
Stopped State 3-10
Quiescent State 3-10
DTE and DCE States During Quiescence 3-10
Call Establishment State 3-12
ADCCP/X21 Signals a Call Request 3-12
DCE Signals Incoming Call 3-13
Netinfo Sequence 3-13
Connected State 3-13
Clearing State 3-14
Call Charges 3-14
Link States for Leased Lines 3-15
vi
Contents
Section 4
Writing Applications that Use ADCCP
Application Tasks 4-1
Opening the Line 4-2
OPEN Procedure 4-5
FILEINFO Procedure 4-7
NUMOUT Procedure 4-8
WRITE Procedure 4-9
AWAITIO Procedure 4-9
ABEND Procedure 4-10
SETMODE Procedure 4-11
Considerations in Opening a Line 4-12
Multiple OPEN Calls 4-12
Unsolicited Messages 4-12
Multiple Processes Opening the Same Line 4-12
Setting Line Options 4-13
WRITEREAD Procedure 4-15
Considerations in Setting Line Options 4-16
Defining the Station List 4-17
Preparing to Receive Asynchronous Messages 4-19
Starting the Link 4-19
START 4-19
MODEM CONTROL 4-19
MODE SET 4-20
RECEIVETEXT 4-20
Transferring Data 4-21
Sending Data 4-21
Receiving Data 4-21
Shutting Down the Link 4-22
Closing the Line 4-22
Error Recovery 4-23
Error Handling and SYSGEN 4-24
Canceling a Request 4-25
Format of Requests and Responses 4-25
Definitions of Fields in Requests 4-26
Definitions of Fields in Responses 4-26
Definitions of Fields in Asynchronous Responses
4-27
vii
Contents
Section 5
Writing Applications that Use ADCCP/X21
Application Tasks
5-1
Opening the Line
5-1
Setting Line Options 5-1
Setting ADCCP Line Options 5-2
Setting X.21 Line Options 5-2
Preparing for Asynchronous Messages
Starting the X.21 Link
5-2
5-2
Requesting or Canceling Optional X.21 Network Facilities
Making an X.21 Circuit-Switched Connection 5-3
Inserting a Selection Signal Sequence 5-3
Anticipating the Netinfo Sequence
5-4
Making an X.21 Leased-Line Connection
5-4
Preparing for Unexpected Disconnects
Performing ADCCP Tasks
5-6
Clearing the X.21 Connection
Closing the Line
Error Recovery
Section 6
5-6
5-7
5-7
Requests and Responses
(1) SET CONFIGURATION
Request 6-2
Response 6-8
6-2
(2) FETCH CONFIGURATION
Request 6-9
Response 6-9
(3) START TRACE
(4) STOP TRACE
6-9
6-11
6-12
(5) FETCH STATISTICS
Request 6-13
Response 6-13
6-13
(6) START OPERATION 6-16
Request for ADCCP 6-16
Response for ADCCP 6-16
Request for X.21 6-16
Response for X.21 6-17
viii
5-6
5-3
Contents
(7) STOP OPERATION 6-18
Request for ADCCP 6-18
Response for ADCCP 6-18
Request for X.21 6-19
Response for X.21 6-19
(8) TRACE BLOCK
6-20
(64) TRANSLATE TABLE
Request 6-21
Response 6-22
6-21
(65) SENDTEXT 6-23
Request 6-23
Response 6-24
(66) RECEIVETEXT 6-25
Request 6-25
Response 6-26
(67) MODE SET 6-29
Request 6-29
Response 6-30
(68) MODEM CONTROL
Request 6-31
Response 6-31
6-31
(69) DEFINELIST 6-32
Request 6-32
Response 6-34
(70) CHANGELIST 6-35
Request 6-35
Response 6-35
(71) SCAN LIST 6-37
Request 6-37
Response 6-38
(72) LINE QUALITY
6-39
(80) SET X.21 CONFIGURATION
Request 6-40
Response 6-41
6-40
(81) FETCH X.21 CONFIGURATION
6-42
(82) CONNECT 6-44
Request 6-44
ix
Contents
Accepting an Incoming Call 6-44
Normal Outgoing Call 6-45
Direct Call 6-45
Selective Direct Call 6-46
Facility Registration and Facility Cancellation
Response 6-47
6-46
(83) DISCONNECT 6-49
Request 6-49
Response 6-50
Status Code Definitions
Appendix A
6-51
File System Error Codes
Recovery Strategies A-1
Path Switches A-1
Total Subsystem and LIU Failures
Power Failures A-3
File-System Error Codes
A-2
A-4
Appendix B
ADCCP Programming Example Using TAL
Appendix C
ADCCP Programming Example Using C
Appendix D
ASCII and EBCDIC Code Conversion
Glossary Glossary–1
Index
Figures
x
Index–1
Figure 1-1.
Station Types in Sample Configurations
Figure 1-2.
NRM Line Control Mode
1-6
Figure 1-3.
ARM Line Control Mode
1-7
Figure 1-4.
ABM Line Control Mode
1-8
Figure 1-5.
ADCCP Frame Format
Figure 1-6.
Station Addressing
Figure 1-7.
Control Field Formats
Figure 1-8.
Frame Sequence Checking
1-9
1-10
1-12
1-14
1-5
Contents
Figure 2-1.
ADCCP Software Layers
Figure 2-2.
Input Frame Handling
Figure 2-3.
Link States and Transitions
Figure 2-4.
Station States and Transitions
Figure 2-5.
MODE SET to a Logically Disconnected Station
Figure 2-6.
Standard Polling
2-13
Figure 2-7.
Alternate Polling
2-15
Figure 2-8.
ADCCP to Token Ring Communication (Option_Two)
Figure 3-1.
ADCCP/X21 Software Components
Figure 3-2.
X.21 Circuits
Figure 3-3.
X.21 Circuit-Switched Link States
Figure 3-4.
X.21 Link States During Quiescence
Figure 3-5.
ADCCP Link States During the Connected State
Figure 3-6.
Link States and Transitions for Leased Lines
Figure 4-1.
WRITEREAD Buffer
4-25
Application Requests
1-2
Tables Table 1-1.
2-2
2-4
2-5
2-7
2-9
2-16
3-2
3-7
3-9
3-11
3-14
3-16
Table 1-2.
Line Configuration Options
Table 3-1.
X.21 Line-Configuration Options
Table 3-2.
CPS Action Table
Table 3-3.
DTE Time Limit Default Values
Table 3-4.
DTE Quiescent States
3-12
Table 3-5.
DCE Quiescent States
3-12
Table 6-1.
Table 6-2.
Descriptions of SET CONFIGURATION Parameters
6-4
Table 6-3.
Status Byte Values for the RECEIVETEXT Response
6-27
Table 6-4.
Status Codes for Successful Requests
Table 6-5.
Status Codes Indicating Resource or Allocation Errors
Table 6-6.
Status Codes Indicating Invalid Request or Format
Table 6-7.
Status Codes Indicating a Failed or Cancelled Request
Table 6-8.
Status Codes Indicating a Fatal Modem Error
Table 6-9.
Status Codes Indicating Frame Errors
Table 6-10.
RECEIVETEXT Responses
1-19
3-4
3-5
3-7
6-1
6-51
6-51
6-52
6-53
6-54
6-55
6-56
xi
Contents
xii
Table 6-11.
Status Codes and Error Details for X.21
Table A-1.
Serious File-System Error Codes– Do Not Retry
Table A-2.
File-System Error Codes– Retry
Table D-1.
ASCII-to-EBCDIC and EBCDIC-to-ASCIICode Conversion
6-57
A-4
A-6
C-1
About This Manual
This manual describes the 6100 Advanced Data Communications Control Procedure
(ADCCP) and X.21 protocol modules. It provides information you need to set up an
ADCCP configuration and write programs that communicate over ADCCP lines or
X.21 interfaces. It is assumed that you know the ADCCP or X.21 protocols and have
read the CP6100 I/O Process Programming Manual. This manual is organized into 6
sections, 3 appendixes, a glossary, and an index:
Section or
Appendix
Title
Contents
1
2
3
4
Writing Applications That Use ADCCP
5
6
Writing Applications That Use
ADCCP/X21
A
B
ADCCP Programming Example Using
TAL
C
ASCII to EBCDIC/EBCDIC to ASCII
Conversion Tables
Introduces the ADCCP protocol and
describes its features.
Describes the management of links and
stations within the ADCCP protocol.
Introduces and describes the X.21 protocol
module.
Describes the steps in creating an
application, the tasks that the application
must perform, and request/response
message formats.
Describes points to consider when writing
applications using ADCCP/X21.
Lists and describes the requests that an
application makes to the ADCCP and
ADCCP/X21 protocol modules and the
response that the protocol module returns
to the application. This section also lists
and describes the status codes that can be
returned in the responses.
Lists the file-system errors that have
special meanings for CP6100, the 6100
subsystem, and 3650/6100 family
controllers.
Presents an annotated sample application
using ADCCP. The example is written in
TAL.
Lists the standard values used for
translation from ASCII to EBCDIC and
EBCDIC to ASCII.
Defines terms used in this manual.
Glossary
Index
xiii
Preface
Who Should Read This This manual is intended primarily for application programmers who will be writing
Manual applications that use the ADCCP or X.21 protocol. It may also be used as a reference
by system managers and data communications specialists. It is assumed that you
understand how to use Guardian 90 procedure calls and know a programming
language.
If the abbreviations or terms used in this manual are not familiar to you, see the
glossary at the end of the manual.
Related Manuals and
Sources of Information
This manual is part of a library of manuals for CP6100. There are also related Tandem
programming and reference manuals and other sources of information that you may
find useful when developing applications that use the ADCCP protocol.
Manual Library for CP6100
The 6100 ADCCP Programming Manual is one of several manuals in the CP6100 manual
library:
CP6100 I/O Process Programming Manual
System Generation Manual for CP6100
6100 MPS-TINET Programming Manual
6100 MPS-B Programming Manual
6100 BSC Programming Manual
Programming Manuals
Programming manuals that may be useful when developing applications are:
Guardian 90 Operating System Programmer’s Guide
Guardian 90 Operating System Programming Reference Summary
C Reference Manual
COBOL Reference Manual
Pascal Reference Manual
Transaction Application Language (TAL) Reference Manual
Standards
Sources of information on the ADCCP and X.21 standards are:
ANSI Standard X3.66-1979, “Advanced Data Communications Control
Procedures”
CCITT Recommendation X.21, “Green Book,” Volume VIII, Fascicle VIII.2,
Geneva, 1988
xiv
Notation Conventions
The following list summarizes the conventions for syntax presentation in this manual.
Notation
Meaning
UPPERCASE LETTERS
Uppercase letters represent keywords and reserved words; enter these
items exactly as shown.
Lowercase italic letters represent variable items that you supply.
Brackets enclose optional syntax items. A group of vertically aligned
items enclosed in brackets represents a list of selections from which you
can choose one or none.
In procedure calls, input parameters (those passing data to the called
procedure) are followed by an I; output parameters (those that return
data to the calling program) are followed by an O.
If a space separates two items, that space is required. If one of the
items is a punctuation symbol, such as a parenthesis or a comma,
spaces are optional.
Parentheses, commas, semicolons, and other symbols not described
above must be entered precisely as shown. Quotation marks around
any symbol indicate that it is not a syntax descriptor but a required
character, and you must enter it as shown.
An exclamation point indicates that a comment follows. In procedure
call descriptions, the comment is either an “i” or an “o” (or both), which
indicates that the parameter is either an input (i) or an output (o)
parameter (or both).
Indicates that the parameter type is an integer (one word).
Indicates that the parameter type is a double word integer (two words).
Indicates that the parameter type is a character string.
Follows a parameter type and indicates a reference parameter. The
number of elements returned varies according to the number of
elements requested.
Follows a parameter type and indicates that the parameter is a
reference parameter; that is, the address of the parameter is passed.
(The statements within the program body must access the actual
parameter contents indirectly through the parameter location.) The
number of elements contained in the parameter is defined by x. For
example, INT:ref:12 defines an integer parameter that is passed by
reference and that has 12 elements.
Follows a parameter type and indicates that the actual value of the
contents of a parameter are passed.
lowercase italic letters
Brackets [ ]
I and O
Spaces
Punctuation
Exclamation point !
INT
:INT(32)
STRING
:ref:*
:ref:x
:value
xv
1 Introduction to 6100 ADCCP
ADCCP is a bit-synchronous data communications line protocol developed by the
American National Standards Institute (ANSI). It is defined in ANSI Standard X3.661979, “Advanced Data Communication Control Procedures.” ADCCP is a superset of
the high-level data link control (HDLC) and synchronous data link control (SDLC)
protocols.
The ANSI definition of ADCCP allows for:
Control of a single point-to-point or multipoint data link
Two-way alternate (TWA) or two-way simultaneous (TWS) transmission
Use of leased or switched facilities
ADCCP features include:
Choice of line control mode
Normal Response Mode (NRM)
Asynchronous Balanced Mode (ABM)
Asynchronous Response Mode (ARM)
Data code transparency
Multiple frame transmission before acknowledgment
Cyclic Redundancy Checking (CRC)
Standard or extended address fields
Standard or extended control fields
Features of the 6100 The ADCCP protocol module runs in a line interface unit (LIU) on a 3650/6100 or
ADCCP Product communications subsystem (CSS) or a 3605/6105 communications controller. The LIU
consists of a communications line interface processor (CLIP) and a line interface
module (LIM). The protocol module is downloaded to the CLIP of the LIU from a disk
file either when the system is cold-loaded or by operator request. A single copy of
ADCCP controls one data communication line.
To use the line controlled by ADCCP, applications make file-management requests,
such as OPEN, READ, or WRITE. These requests are handled by the I/O process,
while other tasks are handled by requests to the protocol module. Requests to the
protocol module are encoded in WRITEREAD calls. The “write” part of the call
delivers the request to the LIU. The “read” part carries the response message back to
the application. Table 1-1 lists the requests an application can make to the ADCCP
protocol module.
1–1
Table 1-1. Application Requests
Request
Description
CHANGELIST
DEFINELIST
FETCH CONFIGURATION
FETCH STATISTICS
Changes station descriptions.
Describes stations on the link.
Retrieves current ADCCP line parameters.
Retrieves line quality information, counts of different types of frames,
and other statistics maintained by ADCCP.
Transmits a mode-setting frame, or prepares a station to receive one.
Establishes or dissolves the modem connection.
Accepts data from a remote station.
Determines polling order.
Transmits data to a remote station.
Supplies values for ADCCP line parameters.
Initializes the driver, raises DTR if the line is leased.
Abruptly terminates all line activity.
Replaces default ASCII to EBCDIC and EBCIDIC to ASCII translation
tables.
MODE SET
MODEM CONTROL
RECEIVETEXT
SCAN LIST
SENDTEXT
SET CONFIGURATION
START OPERATION
STOP OPERATION
TRANSLATE TABLE
In addition to the features of the ANSI definition described at the beginning of this
section, the ADCCP module also supports:
Links that can have up to 255 stations
LIUs that run ADCCP can represent a primary station, a combined station, or one
or more secondary stations.
Address fields that can be from 1 to 4 octets (bytes) long and control fields can be
from 1 to 2 octets (bytes) long.
Note
“Octet” is the ADCCP term for a unit of eight bits. On Tandem systems, a byte is equivalent to an octet.
In this manual the term byte is used instead of octet.
An extended control field (2 bytes) that allows you to send up to 127 frames to a
station without receiving an acknowledgment, or receive up to 127 frames without
sending an acknowledgment.
The following frame types (see the subsection “Unnumbered-Frame Control Field“
later in this section for a description of these frames):
Set Normal Response Mode (SNRM)
Set Normal Response Mode Extended (SNRME)
Set Asynchronous Balanced Mode (SABM)
Set Asynchronous Balanced Mode Extended (SABME)
1–2
Set Asynchronous Response Mode (SARM)
Set Asynchronous Response Mode Extended (SARME)
Set Initialization Mode ( SIM)
Request Initialization Mode (RIM)
Disconnect (DISC)
Request Disconnect (RD)
Reset (RSET)
Unnumbered Acknowledgment (UA)
Unnumbered Information (UI)
Reject (REJ)
Selective Reject (SREJ)
Disconnect Mode (DM)
Frame Reject (FRMR)
Exchange Station Identification (XID)
User-defined frames (USER0, USER1, USER2, USER3)
A data rate on a link up to 56K bits per second for ADCCP.
A data rate on a link up to 64K bits per second for X.21.
Support of the RS-232, RS-449, and V.35 electrical interfaces.
Use of either switched or leased lines.
Use of either half-duplex or full-duplex modems.
Traces of frames:
Transmitted and received on the line
Exchanged by the LIU and the Tandem processor
Traces of events in the LIU.
ASCII-to-EBCDIC translation for outgoing data, and EBCDIC-to-ASCII translation
for incoming data. You can specify which portion of each frame is subject to
translation (on a per-link basis). An application can supply its own translation
tables for input and output.
1–3
6100 ADCCP Concepts and Context
6100 ADCCP Concepts The purpose of the ADCCP protocol is to provide efficient, reliable communication
and Context between computers, terminals, and other devices connected by communication lines.
Each communicating entity is called a station; the connection between stations is called
a link.
In most networks, the stations vary in communications features, range of commands,
and communications authority. For example, if a mainframe is connected to a string of
terminals, the mainframe normally controls the terminals. Even if devices on a link
have the same communications features (for example, two mainframes are connected),
it may be desirable to let one device dominate the other with one device initiating the
communication, and the other responding.
The rules for interaction among the stations on a link are determined by three factors:
Station types
Line-control modes
Line-configuration options
The first two factors define the relationship between or among the stations.
Configuration options further define the protocol. The next few subsections discuss
each of these topics, as well as the frame types and formats characteristic of ADCCP.
Station Types
Station type indicates the relative status of stations on a link. ADCCP recognizes three
types:
Primary station
Controls communication on a data link. A primary station
establishes and ends communication sessions, performs error
recovery, and, in many cases determines when other stations
may transmit or receive data. A link can have only one primary
station.
Secondary station
Communicates under direction of a primary station. A link can
have one or more secondary stations.
Combined station
Acts as a primary and a secondary station. Logically, a
combined station consists of two substations: a primary
substation and a secondary substation.
Figure 1-1 shows the ways these kinds of stations can be combined. The first
configuration has a primary station connected to a secondary station. The second
configuration has a primary station connected to a string of secondary stations. The
third configuration has two combined stations connected to one another.
1–4
Figure 1-1. Station Types in Sample Configurations
A
Primary Station
point-to-point
Secondary
Station
B
Primary Station
multipoint
Secondary
Station
Secondary
Station
Secondary
Station
C
Combined Station
Combined Station
Primary
Substation
Secondary
Substation
Point-to-Point
Secondary
Substation
Primary
Substation
001
1–5
A link that connects only two devices is called a point-to-point link; a link that
connects more than two devices is called a multipoint link. (The primary station on a
multipoint link is sometimes referred to as a supervisor, and the secondary stations
are sometimes referred to as tributaries. This manual uses the terms primary and
secondary only.) Links between combined stations are always point-to-point.
Line-Control Modes
The line-control mode determines the commands a primary station or substation
issues to enable data transmission. The line-control mode also determines how a
secondary station or substation responds to a primary station. ADCCP defines three
modes plus an extended mode for each of the three modes. The three modes are:
In NRM , a secondary station may transmit data only after a request from the primary
station. On a point-to-point line, the primary station polls the secondary station; on a
multipoint line, the primary station polls the secondaries in a round-robin sequence.
(See Section 2, “ADCCP Link and Station Management,” for a more detailed
description of multipoint polling.) Figure 1-2 shows NRM.
In figure 1-2, the primary station issues a SNRM to set up the line. The secondary
station responds with a UA. The primary stations polls the secondary station for data:
RR(P). The secondary station responds with information frames.
Figure 1-2. NRM Line-Control Mode
Link Management (Example)
Primary Station
Data Transfer
Primary Station
SNRM
RR(P)
UA
I
Secondary
Station
Secondary
Station
002
1–6
In ARM, a secondary station may transmit data whenever it is ready; no poll is
required from the primary station. The primary station is responsible for setting up
and dissolving the link; otherwise, the stations function essentially as peers. Figure 1-3
shows ARM.
In Figure 1-3, the primary station issues a SARM to set up the line. The secondary
station responds with a UA. Stations exchange information without a need for polling.
Two-way alternate and two-way simultaneous operation is supported.
Figure 1-3. ARM Line-Control Mode
Primary Station
Primary Station
SARM
I
UA
I
Secondary
Station
Secondary
Station
022
In ABM , two combined stations communicate on a point-to-point link. Either or both
stations issue commands to set up or dissolve the link. (There is no harm in having
both stations issue the commands in parallel; there is also no advantage.) During data
transmission, also, the stations function as peers. Figure 1-4 shows ABM.
1–7
Figure 1-4. ABM Line-Control Mode
Combined Station
Combined Station
SABM
Combined Station
Primary
Substation
UA
Secondary
Substation
Primary
Substation
I
Secondary
Substation
Secondary
Substation
SABM
Primary
Substation
Secondary
Substation
I
Primary
Substation
UA
Combined Station
023
In Figure 1-4, any primary substations issues a SABM to set up the link The
corresponding secondary substation responds with a UA. After a secondary
substation respond with a UA, the primary and secondary stations can exchange
information without a need for polling. Two-way alternate and two-way
simultaneous operations are supported.
Extended Mode
Each of the modes has a corresponding extended mode. In extended mode, the frame
can have an extended address field, an extended control field, or both. Extended
addressing and extended control are independent; one does not imply the other. An
extended address field allows longer addresses, and therefore supports more stations.
(A network should have only as many stations as it has unique addresses.) An
extended control field allows frames to carry larger sequence numbers, so stations can
transmit more frames before receiving an acknowledgment. Both types of extensions
affect the format of frames exchanged over a link but do not affect the relationship of
the stations on a link. The following subsection, “Frame Formats,” describes the frame
formats of the ADCCP protocol.
Frame Formats
1–8
In the ADCCP environment, messages are divided into transmission units called
frames. All frames adhere to the same general format but vary depending on whether
the mode is standard or extended and on whether a frame includes application data in
addition to link control information. Figure 1-5 illustrates the general format of an
ADCCP frame.
Figure 1-5. ADCCP Frame Format
F
A
C
I
FCS
F
Flag
8 bits
Address
Field
8 bits ∗
Control
Field
8 bits ∗
Information Field
(variable)
Frame Check
Sequence Field
16 bits
Flag
8 bits
Legend
∗ In extended mode, the address field can be up to 4 bytes
long, or the control field can be up to 2 bytes long, or both.
003
Flag Sequence
All frames begin and end with a flag sequence. This flag sequence consists of a
leading zero bit followed by six one bits and a trailing zero bit. All stations constantly
monitor the line for the flag sequence, which indicates the start of a message frame and
provides for synchronization timing. The same flag that closes one frame may begin
the next frame, reducing some of the line overhead for sequential (back-to-back)
messages. ADCCP can send two frames separated by one flag and can handle back-toback incoming frames.
Flags can also be transmitted continuously when the line is idle. You indicate whether
flags or ones should be used for this purpose by declaring the FLAGIDLE parameter at
system generation (SYSGEN) or in the configuration block.
Address Field
The address field immediately follows the starting flag. The address field specifies
which stations on a link are exchanging frames. For example, when a primary station
polls a secondary station on a multipoint link, the address specifies the secondary that
the poll is intended for. In its reply, the secondary uses the same address. In general,
a secondary station has one address, and a primary station has one address for each
secondary that it controls. A combined station has two addresses: one for the primary
substation it uses to address a remote combined station, and one for the secondary
substation it uses in responding to a remote combined station. Figure 1-6 shows these
principles of addressing.
1–9
Figure 1-6. Station Addressing
Primary Station
Address
"A"
Secondary
Station
Combined Station
Address
"B"
Secondary
Station
Address
"C"
The primary uses a
Secondary
Station
different address to
communicate with each
secondary station.
Each secondary station
uses only one address.
Combined Station
Primary
Substation
Address "A"
Secondary
Substation
Secondary
Substation
Address "B"
Primary
Substation
Each combined
station has two
addresses. The local
primary substation
has the same address
as the remote
secondary substation,
and vice versa.
004
In standard line control modes (NRM, ARM, or ABM), the address field is 1 byte long.
In extended modes (NRME, ARME, or ABME), the address field can be up to 4 bytes
long. You define the length of the field at system generation, through the
Communications Management Interface (CMI), or in the configuration block through a
(1) SET CONFIGURATION request from the application. You assign addresses to
stations as follows:
For a point-to-point or multipoint link, you assign addresses with an application
request (DEFINELIST).
For an ABM link, you assign the primary substation address with an application
request (DEFINELIST) and the secondary substation address at system generation,
through CMI, or in the configuration block with an application request (SET
CONFIGURATION).
1–10
Once you have assigned addresses to stations, your application does not need to refer
to the addresses because your application uses a station ID established in the
DEFINELIST request.
Control Field
The control field follows the address field. The contents and format of the control
field vary, depending on the type of frame. The control field contains the ADCCP
commands and thus provides the following functions:
Identifies the type of frame
Conveys commands, responses, and status information between communicating
stations
Requests information and acknowledges information received
Places the frame in sequence with other frames for the same station
The ADCCP protocol module builds the control field for the application, which issues
requests for protocol sequences. For example, an application in a primary station
requests a mode-setting sequence before an exchange of messages occurs between two
stations. Requests and the protocol actions that they can cause are described in
Sections 3, “ADCCP/X21 Protocol Module,” Section 4, “Writing Applications That Use
ADCCP,” and Section 5, “Writing Applications That Use ADCCP/X21.”
The control field contains the ADCCP command and has one of three different
formats, each corresponding to a category of link activity. These formats are:
Information
A format used for passing application data over a link between
stations. A frame whose control field has this format is called an
I-frame.
Supervisory
A format used for regulating the flow of data between stations (for
instance, to report that a station is busy or to prod a station that is slow
in responding to an earlier transmission). A frame whose control field
has this format is called an S-frame.
Unnumbered A command/response format used for conveying link commands from
a primary station to a secondary station and for conveying responses
to those commands from the secondary to the primary. A frame whose
control field has this format is called a U-frame.
The low-order bit or bits of the control field specify the frame format. The table bit
sequence of the low-order bits for each type of format is:
Bit 0
Bit 1
Frame Format
0
1
1
x
0
1
I-frame
S-frame
U-frame
1–11
The control field is 1 byte long but can be 2 bytes long in extended control. Figure 1-7
shows the different formats of the control field; the direction of transmission is to the
left.
Figure 1-7. Control-Field Formats
Basic 1-Byte Format
(HDLC, SDLC, ADCCP)
Extended 2-Byte Format
(ADCCP)
First Byte
0
Information
Frame
1
2
0
Ns
LSB
Supervisory
Frame
3
4
5
P/F
MSB
8
Nr
LSB
0
1
2
3
4
1
0
S
S
P/F
5
4
0
8
1
2
3
0
MSB
7
Nr
LSB
Unnumbered
Frame
7
4
Second Byte
5
6
7
8
9
10 11 12 13 14
P/F
Ns
LSB
MSB
Nr
LSB
0
1
2
3
4
5
6
7
8
1
0
S
S
0
0
0
0
P/F
MSB
9
MSB
10 11 12 13 14
8
15
Nr
LSB
4
15
0
1
2
3
5
8
7
0
1
2
3
5
6
7
9
1
1
U
U P/F U
U
U
1
1
U
U P/F U
U
U P/F 0
MSB
10 11 12 13 14
0
0
0
0
0
15
0
Legend
Ns
Nr
LSB
MSB
=
=
=
=
Number Sent Variable
Number Received Variable
Least Significant Bit
Most Significant Bit
S = Supervisory Message Encoding
U = Unnumbered Message Encoding
P/F = Poll/Final Bit Position
005
1–12
Extended Control. The basic control field of 1 byte allows a maximum window size of 8
frames. In extended control, the control field is 2 bytes long, allowing a maximum
window of 128 frames. The poll/final bit for extended control is in bit position 9 for
I-frames and S-frames. For U-frames, it is set in bit positions 5 and 9.
IBM Extended Control (IEC). The IBM Systems Network Architecture (SNA)/SDLC
implementation of extended control differs from the basic ADCCP specification. With
IEC, only numbered frames have a 2-byte field. Unnumbered frames have a 1-byte
field. The following types of ADCCP command/response frames use a 2-byte field in
extended control:
Information
Receive Ready (RR)
Receive Not Ready (RNR)
Reject (REJ)
All other frame types in IEC have a 1-byte field.
Information-Frame Control Field. An I-frame transfers data between two stations. The
control field of an I-frame contains the following three parameters, in addition to the
low-order bit that identifies the frame as an I-frame:
Ns parameter
The link-level sequence number of the I-frame. It places this frame in
relation to others being sent to the same station. For successive
frames, this number increments from 0 to 1 to 2, and so forth, until it
reaches the window size for the line control mode, which is 7 for
standard mode and 127 for an extended mode. The link sequence
number wraps to 0 once it reaches the limit of the window size.
Nr parameter
The link-level sequence number of the next expected I-frame. Thus
the Nr parameter acknowledges receipt of all I-frames with sequence
numbers less than Nr; the next I-frame receive from the other station
should have a sequence number of Nr.
Poll/final bit
The bit that the primary station uses to poll the secondary station. In
NRM, the primary station is requesting a response or a series of
responses from secondary station when the primary station polls a
secondary station. If a secondary station uses this bit, it indicates that
this frame containing the poll/final bit is the last frame in the
sequence of frames sent to the primary station.
In ABM, the primary station uses the poll/final to synchronize the
send and receive count between itself and the secondary station. The
primary station sends an RR frame with the poll bit set to the
secondary station. The secondary station responds with an RR frame
with a final bit set and a count of the frames received from the
primary station.
1–13
With the Ns/Nr scheme of sequence checking, two communicating stations do not
need to acknowledge each frame individually. An acknowledgment must be issued at
least once for every window size. Because the status of an unacknowledged frame is
not known (the frame might have to be sent again), the sending station retains each
frame until it has been acknowledged.
The use of frame sequence numbers is illustrated in Figure 1-7. Notice that once
transmission begins, the Nr values specify the number of the next frame to be received
and that a single Nr value can acknowledge the receipt of several successive frames.
Also note that the acknowledgment pattern shown in Figure 1-8 is somewhat
simplified: it assumes a half-duplex, point-to-point environment. In a multipoint
environment, the primary station must use separate sets of sequence numbers for each
secondary station.
Figure 1-8. Frame Sequence Checking
Primary
Ns
0
1
2
3
Ns
4
5
6
7
0
Secondary
Nr
0
0
0
0
Ns
0
1
2
Nr
4
4
4
Ns
3
4
5
Nr
1
1
1
Nr
3
3
3
3
3
006
Supervisory-Frame Control Field. An S-frame reports whether a station wants to receive
data, and in some cases, which data the station wants to receive. The format of the
control field is similar to the format of an I-frame except that the Ns value (which is
unnecessary because supervisory frames are unnumbered) is replaced by a 2-bit
command code, and the frame identifier is two bits long instead of one. The format
1–14
includes the Nr parameter and can therefore be used to acknowledge received
I-frames.
The command code indicates one of the following types of S-frames:
Receive Ready (RR)
Indicates that all frames with sequence numbers less
than Nr have been received error-free and that the
station is ready to accept further transmissions.
A primary station uses this command to poll a
secondary station, or to probe a station that did not
respond to the last command or poll.
Indicates that the station is busy and that frames with a
sequence number of Nr or greater cannot be accepted at
present. The station may, however, be able to transmit
data.
Reject (REJ)
Requests retransmission starting from the frame with
sequence number Nr.
Requests retransmission of the frame with sequence
number Nr.
Unnumbered-Frame Control Field. A U-frame conveys link commands and responses
between a primary station and a secondary station. The control field for this type of
frame is similar to the control field of an S-frame except that the Nr parameter is
replaced by a 3-bit command or response code.
The ADCCP module uses the following commands and responses:
DISC
This command is used by a primary station to disconnect a specific
secondary station, or by a combined station to dissolve an ABM link. The
expected response is UA or DM.
DM
A secondary station sends this frame when it receives a DISC command or
when an error causes it to become logically disconnected.
FRMR
A secondary or combined station sends this response to indicate that it
received an invalid or improperly formatted frame. A frame might be
invalid because it contains a command not implemented at the receiving
station. An example of improper format is a field of a length incompatible
with the configuration.
RD
A secondary station uses this response to request a disconnect. The
secondary station goes into the logically disconnected state (LDS) when it
receives a DISC response. RD can be the response to any command.
RIM
This response is used by a secondary station to request a SIM command
from the primary station. The secondary can send this response in answer
to any kind of frame to indicate that it cannot respond to other commands
until it has been initialized.
RSET
This command is used by a combined station to reset the Nr and Ns
parameters for a pair of substations.
1–15
1–16
SABM
This command can be used by either one or both combined stations on a
link. It places the link in asynchronous balanced mode. The expected
response is UA. The Ns and Nr counts are reset to zero when this
command is accepted, and the stations are free to transmit data. The
stations stay in ABM until either one transmits a DISC command or another
mode setting command.
SABME
This command is the same as SABM, except that it implies the extended
control field format. It does not necessarily imply an extended address
field.
SARM
This command is used by a primary station to place a link in ARM. The
expected response is UA. The Ns and Nr counts of both stations are reset to
zero. The link stays in Asynchronous Response Mode until the primary
issues a DISC command or any other mode setting command.
SARME
This command is the same as SARM, except that it implies the extended
control field format.
SIM
This command is used by the primary station to trigger device-dependent
initialization activities within a secondary station. UA is the expected
response. The Nr and Ns counts are reset to zero when this command is
accepted.
SNRM
This command is issued by a primary station to a secondary station, and
places the secondary in NRM. (The primary station must issue this
command to each secondary it polls.) The expected response is UA. The
Ns and Nr counts of both stations are reset to zero when this command is
accepted. The secondary stays in NRM until the primary sends it a DISC,
SIM, or a mode setting command.
SNRME
This command is the same as SNRM, except that it implies the extended
control field format.
TEST
This command can be used by either a primary station or a secondary
station to test the link.
UA
A secondary station sends this frame in answer to a SIM, SABM, SARM,
SNRM, SABME, SARME, SNRME, or DISC command.
UI
A primary or secondary station can transmit one frame of information with
this frame type. The information is transferred between the stations with
no link-level acknowledgment. Most applications do not use this frame
type.
USER0
This is a user-defined frame type as defined in the ANSI ADCCP standard.
I-fields are allowed in this frame.
USER1
I-fields are allowed in this frame.
USER2
I-fields are allowed in these frames.
USER3
This a user-defined frame type as defined in the ANSI ADCCP standard.
I-fields are allowed in this frames.
XID
A primary station sends this command to the secondary station, asking it to
identify itself. The secondary responds with another XID frame. This
command is used most frequently in switched networks so that the called
station can find out the identity of the calling station. An XID frame has an
information field containing the necessary data. Specific applications and
devices define what information is required.
Information Field
The information field, if present, contains the application data to be delivered to the
other station. The ADCCP protocol (including the contents of the other fields) exists to
ensure the orderly transmission of the data in the information field. The contents of
the information field is transparent to ADCCP, which regards the data as only a
stream of bits.
The information field can be subject to character code translation. You can specify the
part of the field that you want translated, if any, at system generation time, or through
an application request that makes a change to the configuration block (see the
description of the (1) SET CONFIGURATION request and response in Section 6,
“Requests and Responses”). An application can replace the standard ASCII-EBCDIC
translation tables, supplying its own tables for incoming and outgoing data (see the
description of the (64) TRANSLATE TABLE request and response in Section 6,
“Requests and Responses”).
Sometimes the information field contains control information as well as data. For
example, it might support protocol layers higher than those provided by ADCCP. The
interpretation of the control field determines whether an information field is present
and, if so, what it contains.
Frame Check Sequence Field
The frame check sequence (FCS) field contains the cyclic redundancy check (CRC)
value for the frame. The sending station’s hardware computes the CRC value by
using the address field, control field, and information field (if present) as a continuous
bit stream. An end flag follows the frame check sequence field.
Abort Sequence
An abort sequence occurs when the transmission of a frame must stop abruptly and
tells the receiving station to disregard the frame in which it appears. The ADCCP
protocol module can insert the sequence at any point in the frame. An abort is
distinguished from a flag by the number of consecutive one bits it contains. An abort
sequence consists of at least 7 but no more than 15 consecutive one bits.
A transmission of 15 or more one bits is not an abort sequence. It is one of the options
available for time fill between frames.
A sequence of six or more consecutive one bits cannot occur randomly within the
frame because of zero bit insertion. Zero bit insertion is an error technique in which
1–17
the line controller (here an LIU) automatically inserts a zero after transmitting five
consecutive ones. The converse is occurs when the line controller receives data: a zero
following five consecutive ones is stripped from the input stream.
An application cannot request an abort sequence. If an abort sequence occurs in either
an incoming or an outgoing frame, the ADCCP protocol module informs the
application (which sent or received the data) that the frame was aborted.
Line-Configuration Options
The line-configuration options that you define at system generation specify:
Parts of the electrical interface
Frame formats
Resource utilization
Error-handling strategies for the line
Most of your choices will depend on the hardware features used on the link; for
example, the characteristics of your modems, the delays built into some terminals, the
character code a terminal or mainframe uses, or the expected quality of a line. A few
of your choices will depend on tuning or architectural considerations; for example, the
most efficient size of a frame or whether you should operate two mainframes as peers
rather than as master and slave.
Table 1-2 lists the line-configuration options in five functional categories. For detailed
descriptions of these options, refer to the System Generation Manual for CP6100 or see
Table 6-2 in Section 6, “Requests and Responses,” of this manual.
1–18
Table 1-2. Line Configuration Options
Error Handling
Frame Format
Line and Modem
Control
Character Code Transmission
Transmission Control
L1RETRY
L2RETRY
NOREJ
SREJ
T1TIMER
TESTFRAME°
THRESHOLD
XFERTIMER
AFLD
EXTENDED
MAXFRAME
DSRTIMER
FLAGIDLE
HALFDUPLEX
XLENGTH
SWINCARRIER
SWITCHED
SWINOUTCARRIER
TRANSLATE
XOFFSET
ABMIPON°
ABMSUPPON°
ADDRESS
IDLETIMER
MODE*
NOCARRFATAL
OPTIONA°
OPTIONB•
POLL
STATIONS
SUPRESSRR°
TWA
TWS
WINDOW
* Mode is set at system generation time through the ABMMODE, ARMMODE, or NRMMODE modifiers.
° Can be set only by using the (1) SET CONFIGURATION request.
• A reserved byte in the configuration block.
Note
Any parameter that you set for the local station must be consistent with the operation of the remote
station. In some cases, the settings must be identical. For example, line control mode and window size
must match on both sides of the link. In other cases, the settings must be complementary. For example,
if a primary has a switched input carrier, the other stations on the link must have switched output carriers.
1–19
2 ADCCP Link and Station
Management
This section provides the following background information that you will need to
write applications that use the ADCCP protocol:
The states through which a line or station moves during its operation, and the
changes induced by application requests or by the actions of remote stations. This
information is useful for error handling and problem determination.
The demands on LIU buffer space, from which you can deduce the number of
stations a link will support and the amount of data the link can handle at a given
time (that is, the maximum number of outstanding frames on a link).
Protocol Task Several levels of software in the host and in the LIU handle the request that an
Architecture application makes to the ADCCP protocol module (or to a station on an ADCCP line).
The levels of software are:
Application process
CP6100 I/O process
Protocol Manager
Station Manager (Level 2 Protocol)
Link Manager (Level 1 Protocol)
Driver
These levels of software perform the following tasks when sending data:
1.
The application process makes the file management calls.
2.
CP6100 directs the requests to the 6100 subsystem.
3.
The ADCCP Protocol Manager receives requests from CP6100 and responds to
CP6100 as each request is satisfied.
4.
The ADCCP Level 2 Protocol, or Station Manager, maintains mode and status
information about each station on the link and makes all protocol decisions that
depend on that information.
5.
The ADCCP Level 1 Protocol, or Link Manager, prepares and issues requests to a
driver routine.
6.
The driver routine controls the modem interface and moves data between the line
and the Level 1 Protocol.
Figure 2-1 shows the major levels of software and the order in which they perform
their tasks when sending and receiving data.
2–1
Figure 2-1. ADCCP Software Layers
Tandem System
CLIP
3
1
2
Application
Process
CP6100
I/O Process
Protocol
Manager
4
5
Level 2
Level 1
Station
Link
Manager Manager
6
Driver
Communications
Line
11
10
9
8
7
Legend
1 Application makes Guardian WRITEREAD call.
2 CP6100 routes the request to the protocol task.
3 The Protocol Manager receives the request and calls Level 1 or Level 2.
4 Level 2 handles requests related to particular stations.
5 Level 1 prepares output frames for transmission.
6 The driver moves the data to the line.
7 The driver captures data from the line.
8 Level 1 disassembles the input frame.
9 Level 2 performs any protocol action required by the input frame.
10 The Protocol Manager responds to CP6100.
11 CP6100 completes the application request.
007
2–2
A request does not need to pass through all levels of the software shown in Figure 2-1.
The Protocol Manager decodes each request and routes it to the appropriate level. In
general, the following cases would not require the use of every level of the software:
The request does not entail action on the line (for example, the request simply
changes or retrieves configuration data). In this case, the Protocol Manager
handles the request without involving lower levels of software.
The request entails an action on the line but does not address a specific station. In
this case, the Level 1 Protocol handles the request, using the driver routine.
Modem-control requests fall into this category.
The request entails communication with a specific station. In this case, the Level 2
Protocol handles the request. Level 1 takes output frames from Level 2 and uses
the driver routine to place the frames on the line.
Not all protocol actions are triggered by application requests. A frame arriving on the
line might satisfy a request, but it can also be a command or response from a remote
station. When a frame arrives, the driver receives it. The Level 1 Protocol checks the
address to identify the remote station and passes the frame to the Level 2 Protocol.
Level 2 sends any required response to the remote station, passing its output frame to
Level 1 for transmission. If the arriving frame is intended for the application (for
example, if it is an I-frame), Level 2 informs the Protocol Manager, which responds to
the application. Figure 2-2 presents a simplified view of the ADCCP protocol module
handling input frames. Frame handling is described further in, “Polling,” later in this
section.
2–3
Figure 2-2. Input Frame Handling
3
2
1
Frame
Protocol Level 2
Level 1
Manager Station
Link
Manager Manager
Driver
Line
Response
7
6
4
5
Legend
1 The frame arrives, and the driver receives it.
2 Level 1 checks the address and passes the frame to Level 2.
3 Level 2 queues a response frame for Level 1.
4 Level 1 prepares the response frame for transmission.
5 The driver puts the response frame on the line.
6 Level 2 informs the Protocol Manager.
7 The Protocol Manager completes an outstanding request.
008
Link States and The Level 1 Protocol functions as a “state machine.” At any given time, the link is in
Transitions one of four states:
DISCÎDLE
DISC^WAIT
READYÎDLE
XMIT
Application requests and arriving frames are “events” that may change the state of the
link. Only certain events make sense for each state. For example, an application
cannot send data if the link is disconnected.
Figure 2-3 shows the major link states and the events that cause state transitions.
2–4
Figure 2-3. Link States and Transitions
Line Downloaded
DISCÎDLE
ADCCP Asserts DTR
DSR Timeout
Disconnect
Request or
Modem Error
DISC^WAIT
Modem Asserts DSR
READYÎDLE
Receives Data
Frame Queued
for Output
Frame
Sent
XMIT
009
DISCÎDLE State
The DISCÎDLE state occurs after the LIU has been downloaded and started with
CMI, but before ADCCP has asserted a DTR signal to the modem. The DISCÎDLE
state can also occur if the modem was reset by an application request or link error.
In the case where the LIU has been downloaded and started with CMI, the DISCÎDLE
state persists while the application opens the line, possibly sets or modifies the line’s
configuration, and starts the line with the START request. If the line is a leased line,
the START request causes a state transition. If the line is a switched line, the
application issues a START request, then a MODEM CONTROL request.
If a STOP request puts the line in the DISCÎDLE state, the state persists until the
application issues either a START request or a START request and then a MODEM
CONTROL request. If a MODEM CONTROL request caused the line to be
disconnected, the state persists until the application makes a MODEM CONTROL
connect request.
DISC^WAIT State
In the DISC^WAIT state, the application has issued a START request (for a leased line)
or a MODEM CONTROL connect request (for a switched line). The state lasts until the
modem asserts DSR or until the application issues a disconnect request.
2–5
READYÎDLE State
In the READYÎDLE state, a modem connection exists and the Level 1 Protocol is
ready to receive frames. If an application requests a disconnect function while the line
is in the READYÎDLE state, the state changes to DISCÎDLE.
If an application makes a request to send data to a specific station, the state changes to
the XMIT state. The Level 1 Protocol enters the XMIT state when either the Level 2
Protocol has a frame to send due to a SENDTEXT request or a protocol response is
required from the Level 1 Protocol. Similarly, the Level 2 Protocol interprets the input
frame and queues a response frame for transmission by the Level 1 Protocol. The
queuing of an output frame for Level 1 causes the transition to the XMIT state.
If no application requests are made to send data to a station but there are requests to
receive data (RECEIVETEXT requests), the state can still change from the
READYÎDLE state to the XMIT state. If the local station is a primary in the Normal
Response Mode (NRM) or if the POLL option is selected in some other mode, the
Level 2 software routinely polls the stations on a line. To poll a station, the Level 2
software queues a frame with the poll bit set for transmission by the Level 1 Protocol.
The queuing of this frame causes a transition to the XMIT state.
The expiration of the T1TIMER can also cause a state transition. When this timer
expires, the Level 2 Protocol queues each retry for transmission by the Level 1
Protocol, changing the link state to XMIT.
XMIT State
In the XMIT state, one or more frames are queued for output on the line. If the
XFERTIMER expires in this state, the link stays in the XMIT state until the retries are
exhausted. The XMIT state persists while the Level 1 Protocol:
Prepares each output frame for transmission
Calls the driver
Waits for the driver to report that frames are on the line
Normally, when the XMIT state has completed a transmission, the link returns to the
READYÎDLE state.
Note
The Level 1 Protocol can still receive frames while it is in the XMIT state.
Station States and The Level 2 Protocol (Station Manager) handles communication with remote stations.
Transitions The commands or responses that it issues:
Establish the link
Determine whether a station can be polled or have data sent to it
Disconnect a malfunctioning station
Level 2 maintains one control block and one state machine per station. If the NonStop
system is a primary station, Level 2 redefines that station once for each remote station
on the link. If the NonStop system is a group of secondary stations, Level 2 keeps a
separate control block and state machine for each secondary station. The (70)
CHANGELIST, (69) DEFINELIST, (67) MODE SET, and (71) SCAN LIST requests also
2–6
affect station information maintained by Level 2. (See Section 6, “Requests and
Response,” for a description of these requests.)
The state machine or machines maintained by Level 2 can be in one of four states:
Logically disconnected state (LDS)
Mode-setting state
Initialization state (IS)
Information-transfer state (ITS)
These states apply to the local station, not to the remote station with which it is
communicating. Figure 2-4 shows the basic station states and the events that cause
state transitions.
Figure 2-4. Station States and Transitions
Line Downloaded
and Started
Disconnect Request
or Modem Failure
Logically
Disconnected
State (LDS)
MODE SET
Request
Disconnect Request
or Modem Failure
DISC
Sequence
Modem Failure
Mode-setting
State
MODE SET
Request
MODE SET
Request
SIM
Sequence
Initialization
State (IS)
SNRM(E),
SARM(E),
or
SABM(E)
Sequence
Information
Transfer
State (ITS)
010
2–7
Note
Logically Disconnected
State (LDS)
Although the ADCCP protocol module never explicitly reports the state to an application, you can often
determine the state. For example, if you send a SNRM frame to a station and have not received the
completion, the local station is in the Mode Setting state (unless some error has occurred or is occurring,
or the UA just arrived and you have not discovered it yet).
The logically disconnected state (LDS) applies from the time the line is started with
CMI until an application makes a MODE SET request to establish the link. A station
can also enter this state as a result of one of the following conditions:
Modem failure
Serious line error
MODEM CONTROL request that disconnects the line.
MODE SET request that disconnects the station
protocol error (for example, a FRMR from a remote station)
A station in the LDS can be in either DEAD or DISC mode. If the station is in DEAD
mode, the ADCCP protocol module discards any frames that arrive for that station. If
the station is in DISC mode, the protocol module accepts unnumbered commands that
arrive for the station, but rejects all other frames. (The response to a mode-setting
frame is UA; the response to other frames is DM.)
A secondary station normally leaves the LDS when it receives a mode-setting frame
(like a SIM or SNRM) from the line. To receive a mode-setting frame, the station must
be in DISC mode rather than DEAD mode. To change the mode from DEAD to DISC,
the application makes a MODE SET request as shown in Figure 2-5. If the secondary
station requires a SIM from the primary station, the application specifies SIM rather
than DISC in its MODE SET request. The secondary then responds with a RIM to
every frame until it receives a SIM on the line. When a mode-setting frame arrives on
the line, the station moves into the Mode Setting state. After sending the UA response,
the station can move into one of two states:
Initialization State (IS) if the frame was a SIM
Information Transfer State (ITS) if the frame was a SNRM, SNRME, SARM,
SARME, SABM, or SABME
Normally, a primary station leaves the LDS when an application in the primary station
issues a MODE SET request to initiate a mode-setting sequence (like SIM or SNRM)
on the line.
2–8
Figure 2-5. MODE SET to a Logically Disconnected Station
Primary Station
If the station is DEAD–for
example, if ADCCP was just
downloaded–it does not
respond to a modesetting
frame. It remains in Logically
Disconnected state.
SNRM
Secondary Station
in DEAD Mode
After the application makes
a MODE SET request, the
station enters DISC mode
and Mode-setting state.
Application
MODE SET
Secondary Station
in DISC Mode
Primary Station
Now, the station can respond
to a mode-setting frame.
SNRM
UA
Secondary Station
in DISC Mode
In this example, the station
enters Normal Response
Mode and Information
Transfer State.
Primary Station
RR(P)
Application can now
I
request data transfer
operations.
Secondary Station
in NRM
011
2–9
Mode-Setting State
The mode setting state is the state of a primary or combined station during a modesetting sequence. The mode-setting sequence begins from the time that a station puts
a mode-setting frame (DISC, SNRM, SNRME, SARM, SARME, SABM, SABME, SIM, or
RSET) on the line and ends when a UA frame arrives from the remote station. The
state then changes to:
LDS if the mode-setting frame was a DISC
IS if the mode-setting frame was a SIM
ITS for any other mode-setting frame
If the mode-setting sequence times out and retries (L2RETRY) are unsuccessful, the
state changes to the LDS. A secondary station is in MODESETTING state from the
time it receives a mode-setting frame from the primary station until the secondary
sends a UA response to that mode-setting frame.
Initialization State (IS)
Information-Transfer State
(ITS )
Initialization State (IS) is the state of a primary or secondary station after a SIM modesetting sequence has been completed on the line, but before the primary has issued one
of these frames: SNRM, SNRME, SARM, SARME, SABM, or SABME. The application
controls the initialization state.
Information transfer state (ITS )is the state that a station enters when a primary station
has sent a mode-setting frame (SNRM, SNRME, SARM, SARME, SABM, or SABME),
and the secondary station has responded with a UA. The local station stays in this
state until:
A mode-setting sequence
A modem control request
An error occurs to disconnect the station
The Level 2 Protocol also maintains data on station conditions for use while a station is
in ITS. The application can issue requests to change these conditions. The conditions
on which the Level 2 Protocol maintains data are:
2–10
DRNR
Occurs when the remote station has transmitted an RNR frame,
indicating that it cannot receive any I-frames. As long as this
condition exists, application requests to send data (SENDTEXT) to the
remote station are delayed.
ERRORSTOP
Occurs when ADCCP suspects a line failure or hardware problem in
the remote station. The application receives an asynchronous line
quality report. Application requests to send data to the remote station
fail, and incoming frames from the station (if any arrive) are
discarded. An application CHANGELIST or DEFINELIST request can
clear the ERRORSTOP condition, usually after someone has solved the
line or hardware problem.
FRMROUT
Occurs when the local station has transmitted a FRMR or RSPR frame
and is waiting for a mode-setting frame or request to clear the
condition. (A primary station expects a MODE SET request from the
application. A secondary station expects a mode-setting frame to
arrive on the line.) Application requests to send data will fail, and
arriving frames for the station are discarded until the mode-setting
frame arrives. The ADCCP protocol module responds to an arriving
frame with the poll bit set by sending another FRMR or RSPR frame
with the poll bit set. (A combined primary substation sends a RSPR.
A secondary substation sends a FRMR.)
LRNR
Occurs when an application requests a station RNR, demanding that
the local station refuse incoming I-frames. When an application
requests a station RNR, the application can send data to the remote
station, but the ADCCP protocol module discards I-frames arriving
from the remote station. The local station sends RNR supervisory
frames, instead of the RR frames it would send if it wished to receive
data.
NOPOLL
Occurs when an application requests it. In this situation, the
application’s requests to send data fail, and all incoming frames are
discarded. The local station behaves as if it were dead, except that the
station remains in the same state it was in prior to its “dead” behavior.
An application request can clear the NOPOLL condition.
REJOUT
Occurs when the local station has sent a REJ frame and is expecting
the arrival of the rejected frame. Incoming frames are discarded until
the expected frame arrives. If the T1TIMER expires before the
expected frame arrives, a primary or combined station transmits an
RR frame with the poll bit set. If the permitted number of retries is
exhausted:
The ERRORSTOP condition occurs.
The station state changes to LDS (DEAD).
SREJOUT
Occurs when the local station has sent an SREJ frame and is expecting
the arrival of the rejected frame. Incoming frames are held pending
receipt of the expected frame. If the T1TIMER expires before the
expected frame arrives, ADCCP discards the frames that were being
held and sends a REJ to the remote station.
2–11
Polling
Polling
One of the important tasks of the Level 2 Protocol is polling, in which a primary
station gives each secondary, in turn, the right to transmit. There are two types of
polling provided in the Tandem implementation of the ADCCP protocol:
Standard Polling
Alternate Polling
Standard Polling
If the line operates in Asynchronous Response Mode (ARM) or Asynchronous
Balanced Mode (ABM), there is no need for either station to poll the other for data.
Either station may transmit at any time (although stations using two-way alternate
transmission cannot transmit simultaneously). If you want polling to occur in ARM or
ABM so each station knows the other is ready, specify the SYSGEN POLL parameter.
If the POLL parameter is set, the ADCCP protocol module sends RR frames to the
remote station when the line is idle. The line is idle when the local station has no data
to send (no SENDTEXT requests are pending) but would like to receive data. The
IDLETIMER parameter specifies the interval between polls.
In Normal Response Mode (NRM), polling occurs automatically when the line is idle if
the local station is the primary station on a point-to-point line. The POLL parameter
does not apply in this case, but IDLETIMER does, specifying the interval between poll
frames.
If the local station represents one or more secondary stations, the local station does not
do any polling; it only responds to them. If a secondary station is polled and has data
to send (it has data if a local application made a SENDTEXT request for that station), it
responds to the poll with data. If the secondary station is polled and does not have
data to send, it responds with an RR frame. (The responses described here are the
normal responses. A station with an LRNR, NOPOLL, or ERRORSTOP condition
behaves as described earlier in the subsection “The Information Transfer State (ITS).”)
If a secondary station is busy, it responds to the primary station with an RNR frame
with the final bit set, and the primary station polls the next station in the list. When
the secondary station is again polled and responds by sending an RR frame with the
final bit set, indicating it is no longer busy, the primary station holds outstanding
I-frames for the secondary station until all other remote stations have been polled.
Figure 2-6 shows the sequence of frames exchanged in standard polling. (The
numbers in the illustration indicate the station.)
2–12
Polling
Figure 2-6. Standard Polling
Primary
Station
Secondary
Stations
I (1)
RR-P (1)
RNR-F (1)
RR-P (2)
RR-F (2)
RR-P (1)
RR-F (1)
RR-P (2)
RR-F (2)
I (1)
RR-P (1)
RNR-F (1)
019
The most complex polling occurs in cases where the line is in NRM and multipoint,
and the local station is the primary station. In these cases, the local station controls all
transmission on the link. Whenever requests for data (RECEIVETEXT) are pending
but there are no requests to send data (SENDTEXT), the ADCCP protocol module
polls the remote stations in round-robin fashion. When every remote station has had a
chance to transmit, the ADCCP protocol module waits for an interval of IDLETIMER,
then starts polling again. (A SENDTEXT request from an application can interrupt the
poll.) Once the ADCCP protocol module has sent the data to the specified station,
polling resumes where it left off. Although a poll may be posted in the idle time
between two frames, the poll is transmitted until the SENDTEXT frames have been
transmitted.
Several factors determine which stations are polled and in what order. If the local
station has a NOPOLL or ERRORSTOP condition, the corresponding remote station is
not polled. Likewise, if the local station is not in ITS, the remote station is not polled.
Remember that the local station can be in different states for different remote stations.
Also, an application can control station states to manage flow control. For example, by
setting LRNR, the application can call for RNR polling frames to be sent to particular
stations, while RR frames are sent to other stations.
To determine the polling order, the ADCCP protocol module refers to two lists. Both
lists result from specific application requests:
2–13
Polling
Station list
The DEFINELIST request creates the Station List. The station list can
later be modified with the CHANGELIST request. If the local station
represents one or more secondary stations, the list contains one entry
for each secondary represented. If the local station is a primary station,
the list redefines the local station once for each remote secondary.
An entry in the station list indicates the station type, the line control
mode, and the station address. (Each time you define the primary
station, it has a different address. The address of the primary station
must match that of the remote secondary station.) The list entry also
identifies the active, RNR, NOPOLL, or ERRORSTOP condition of the
station.
Each entry in the list contains a station ID, which is a number that
ADCCP and all applications use to identify the station. Station IDs
have a range of 1 through 255 for multipoint lines. The station ID must
be 1 for point-to-point lines or 0 for a broadcast station. Any
application request that refers to a particular station uses its station ID,
rather than its address.
Scan list
Alternate Polling
2–14
The SCANLIST request creates the scan list. It consists of a list of
station IDs in the order in which you want polling to occur. The Scan
List may include the same station more than once. For example, you
might want one station polled twice as often as another station. If no
application issues a SCANLIST request, the stations are polled by
increasing value of the station ID. If several applications make
SCANLIST requests, the most recent request always applies. The most
recent request even preempts a poll cycle that is in progress.
In alternate polling (Option_One Polling), the primary station sends outstanding
I-frames to a secondary station as soon as the secondary station indicates that is it no
longer busy. The primary station does not wait to send I-frames until after the polling
of all other remote stations . Alternate polling is useful when the station list is long
and a timeout may occur on the remote station before all other stations are polled.
Figure 2-7 shows the sequence of frames exchanged in alternate polling. (The numbers
in the illustration indicate the station.)
ADCCP-to-Token Ring Communication
Figure 2-7. Alternate Polling
Primary
Station
Secondary
Stations
I (1)
RR-P (1)
RNR-F (1)
RR-P (2)
RR-F (2)
RR-P (1)
RR-F (1)
I (1)
RR-P (2)
RR-F (2)
RR-P (1)
RNR-F (1)
021
ADCCP-to -Token Ring When a token ring controller receives a SNRM frame from a primary station, the
Communication controller sends a SNRM frame to the appropriate secondary station in the token ring
and returns a DM frame to the primary station. When the controller receives a UA
frame from the secondary station in the token ring, the controller sends a UA frame to
the primary station that sent the SNRM frame. To allow the primary station enough
time to wait for the UA response from a station in the token ring, your application
must turn on Option_Two.
In Option_Two, the primary station ignores the DM frame and waits for the UA frame
until the T1TIMER expires then sends another SNRM. The primary stations retires
sending a SNRM to the number of times specified by the L2RETRY line option. Figure
2-8 shows Option_Two behavior between a primary station using ADCCP and a
secondary or combined station using a token ring controller. (Token ring is not a
station type for ADCCP.)
2–15
Figure 2-8. ADCCP-to-Token Ring Communication (Option_Two)
Primary Station
SNRM
(T1TIMER starts)
DM
Token Ring
Controller
SNRM
To Stations
(T1TIMER expires)
UA
SNRM
UA
024
To turn on Option_Two, your application sets the 0 bit of the OPTIONA field of the
configuration block with the (1) SET CONFIGURATION request. See Section 4,
“Writing Applications That Use ADCCP,” for a description of how to set line options,
and Section 6, “Requests and Responses,” for a description of the configuration block
and the (1) SET CONFIGURATION request.
If Option_Two is off, the primary station expects a UA frame in response to a SNRM
frame sent to a secondary station. If the primary station does not receive a DM or UA
frame from the secondary station, the primary station makes only one retry of the
SNRM frame after the T1TIMER expires. If the primary station, receives a DM frame,
your application determines the primary station’s response to a DM frame (usually a
DISC).
Station and Data
Capacity on Links
The LIU buffer space that is available to the ADCCP protocol module limits the
following:
The number of stations that a link can support.
The amount of traffic that the link can sustain.
By considering the various demands on the ADCCP protocol module’s buffer space,
you can make decisions about sizing, tuning, and application design.
The ADCCP protocol module allocates and retains buffers for the following data:
Outgoing frames that have not yet been acknowledged by the remote station.
Incoming frames that the ADCCP protocol has not yet acknowledged to the
remote station (for example, frames that have arrived since the station transmitted
an SREJ frame).
A control block for each station on the link.
Two buffers for trace-related data, if a trace is in progress.
2–16
The SYSGEN MAXFRAME parameter determines the size of each input and output
buffer. The size of a buffer is calculated as follows:
size
=
+
+
+
MAXFRAME bytes (for the information field)
4
bytes (for the address field)
2
bytes (for the control field)
12
bytes (for ADCCP internal information)
The address length and control field length that you define at system generation do
not affect the size of the buffer that the ADCCP protocol module allocates. The size of
an actual outgoing or incoming frame does not affect the size of the buffer either. The
protocol module always allocates space for the largest possible buffer.
The WINDOW and STATIONS parameters determine the total space allowed for
input/output buffers. Each station can have as many output buffers as the window
size allows. All stations together can have one window of buffers. Thus, the total
space allowed for buffers is calculated as follows:
(size
x
STATIONS x
WINDOW)
!
!
output buffers
+
(size
x
WINDOW)
!
!
input buffers
Of this space allowed for buffers, ADCCP permanently allocates only a small portion
to the buffers as follows:
size
x
(WINDOW + 3)
The rest of the space is allocated in response to application traffic.
Note
The criteria of size x (WINDOW + 3) must be met; otherwise, the line will not start.
The STATIONS parameter (defined at system generation or with a SET
CONFIGURATION request) determines the maximum space used for station control
blocks. The largest station list is calculated as follows:
STATIONS x 26
bytes
ADCCP allocates two trace buffers while a trace is in progress , each large enough to
contain a trace block (as defined in the CMI TRACE command).
Without proper planning, you could possibly to set up a link whose memory
requirements vastly exceed the memory available on the LIU. For example, if you
define 255 stations, a window size of 127, and a maximum I-field size of 2046, the
memory requirement would (excluding possible trace buffers) exceed the total amount
of memory available on the LIU, which is 16K words. The calculation for this link
would be:
((2046 + 4 + 2 + 12) x 255 x 127) + 127(2046 + 4
=
67104768
=
65532K
=
32766K
+ 2 + 12)
bytes
bytes
words
2–17
Note
The total amount of memory available on the LIU varies depending on the LIM type and the release level
of microcode.
If you are having problems with memory allocation, you can make the following
adjustments in your configuration or your application:
2–18
1.
Modify the application so smaller frames are exchanged between stations and
change the MAXFRAMES parameter accordingly. (If a device requires a large
frame size, this change might not be feasible.) However, changing the frame size
must be coordinated with other stations on the link. If the frame size is too small,
the station may be disconnected when it receives a large frame.
2
Do not run a trace on a fully loaded line. If you are running a trace to debug a
problem, you have probably stopped important applications.
3.
Change the WINDOW parameter to provide for fewer outstanding frames per
station. (If the application requires a very large window size, use fewer stations
per line.)
4.
Modify DEFINELIST requests to include fewer stations. (This will have only a
small impact on performance.)
5.
Reduce the traffic on the link. The ADCCP protocol module dynamically allocates
the majority of its buffer space as applications make SENDTEXT requests or as
frames arrive on the line. To reduce traffic, an application can put some stations
into an RNR condition, or a system manager can use CMI to suspend some
stations temporarily. If you cannot disable stations, consider moving some
stations to another line.
3 ADCCP/X21 Protocol Module
X.21 is a CCITT recommendation that specifies the physical and functional interface
between data terminal equipment (DTE) and data circuit-terminating equipment
(DCE) for synchronous operation on circuit-switched public data networks. This
interface is defined in the CCITT Recommendation X.21 of 1980 and 1988.
X.21 networks provide either circuit-switched or leased connections between host
systems. Once an X.21 connection is set up, the network passes user data
transparently between the endpoints. The X.21 network does not impose a packet or
any other structure on the bit stream while a connection is established.
Features of ADCCP/X21 provides an X.21 call-control interface within the ADCCP protocol
ADCCP/X21 module. ADCCP/X21 is downloaded into a 3650/6100 CSS or 3605/6105
communications controller, where it is executed by microprocessor circuitry in an X.21
LIU. The X.21 LIU consists of a CLIP 1 connected to an X.21 LIM. The ADCCP/X21
module is stored as a disk file and downloaded into the CLIP’s RAM when the system
is cold loaded or by operator request.
ADCCP/X21 allows your application to set up an X.21 circuit-switched connection
and then communicate over the circuit using the ADCCP bit synchronous
communication line protocol. The features of ADCCP/X21 lines allow your
application to:
Make different types of outgoing call requests. Depending on the call control
features provided by your X.21 network, an application can make the following
types of calls:
Normal calls using either full or abbreviated addressing
Direct calls
Selective direct calls
Accept incoming calls.
Transfer data over either a switched or leased X.21 network connection. (The
maximum is 64 K bits per second.)
Determine the action that ADCCP/X21 takes for each class of call progress signal.
Automatically retry certain types of unsuccessful calls.
Deliver the following information to your application:
Identification of the calling station when a call request comes in from the
network
Identification of the called station when a connection request that you have
made has been accepted
Charging information for the call after an X.21 connection has been cleared
3–1
ADCCP/X21 Protocol Task Architecture
ADCCP/X21 Protocol ADCCP/X21 uses almost the same protocol task architecture as 6100 ADCCP. (Refer
Task Architecture to Section 2, “ADCCP Link and Station Management,” for a description of the ADCCP
protocol task.) The 6100 ADCCP protocol module and the ADCCP/X21 protocol
module both use the following:
Protocol Manager
Station Manager (Level 2 Protocol)
Link Manager (Level 1 Protocol)
However, ADCCP/X21 differs from the ADCCP protocol module in the following
ways:
A different driver handles the X.21 LIM, X.21 Patch-Panel, or X.21 backplane
interconnect card (BIC) interface.
A call control task module manages the special X.21 call control features during
connection establishment and release.
Figure 3-1 shows the main software components in the ADCCP/X21 protocol module.
Figure 3-1. ADCCP/X21 Software Components
CLIP 1
To Host
ADCCP
Protocol
Task
X.21
Driver
X.21
LIM
X.21
Interface
Circuits
Call-Control
Task
013
ADCCP Protocol Task
3–2
The protocol task does most of its work after an X.21 connection has been established
and your application is ready to start an ADCCP link and transfer data. The protocol
task provides the same protocol management, station management, and link
management functions provided by 6100 ADCCP, but the protocol task provides these
functions only after the call-control task has completed call-establishment procedures.
The functions of the protocol task thus depend on the state of the line:
During call establishment and release, the protocol task manages the interface
between the call-control task and CP6100. The call control task has control over
the X.21 line and has exclusive access to the X.21 driver.
After a network connection is established, the protocol task takes control of the
X.21 line and has access to the X.21 driver.
Call-Control Task
X.21 Driver
The call-control task is responsible for managing the X.21 call establishment and call
clearing procedures. During connection establishment, the call-control task handles
host requests and controls the X.21 driver. All host requests and driver control passes
to the ADCCP protocol module once a connection is established. The call-control task
remains inactive until the connection is released. When a connection release is
requested, the call-control task regains control of the X.21 driver until the release
procedures are complete.
The X.21 driver manages all physical I/O with the X.21 LIM. The driver is controlled
by the call-control task during call establishment. After an X.21 connection is set up,
the ADCCP protocol module controls the driver. The control of the driver allows the
protocol module to establish the ADCCP protocol over the X.21 link and totransfer
data. If the connection-clearing phase is initiated, driver control is passed back to the
call control task.
Line-Configuration ADCCP/X21 line-configuration options fall into two groups:
Options
ADCCP configuration options that specify parameters for ADCCP transmission
control, frame format, character code translation, and error handling. You define
these options at system generation, the same as you do for the 6100 ADCCP
protocol module or with a (1) SET CONFIGURATION request.
Configuration options that specify X.21 attributes. These options define values
that the call-control task uses in connection establishment and clearing phases.
You can define these options by issuing a (80) SET X.21 CONFIGURATION
request.
ADCCP Line-Configuration
Options
Note
X.21 Line-Configuration
Options
Most of the 6100 ADCCP line-control and modem-control options are not applicable to
ADCCP/X21. These options refer to features of the RS-232 interface, which have no
application in the X.21 interface. If you specify any of them in the SYSGEN
configuration file, they are ignored by ADCCP/X21.
Table 1-2 in Section 1 lists the line configuration options that you can define in SYSGEN to modify
ADCCP protocol attributes.
Table 3-1 lists the ADCCP/X21 line configuration options that modify X.21 interface
attributes. Most of these options are set to default values recommended by the CCITT.
If you need to modify any of the default values, issue a WRITEREAD with a SET X.21
CONFIGURATION request. (See Section 6, “Requests and Responses,” for a
description of the SET X.21 CONFIGURATION request.)
3–3
Table 3-1. X.21 Line-Configuration Options
Line and Modem Control
Call Establishment
DTE Time Limits
CIRCUIT-SWITCHED
NOT READY STATE
ACCEPT CHARGES
CPS ACTION TABLE
RETRY INTERVAL
RETRY MAXIMUM
TIMELIMIT T1
TIMELIMIT T2
TIMELIMIT T3A
TIMELIMIT T3B
TIMELIMIT T4
TIMELIMIT T5
TIMELIMIT T6
TIMELIMIT T7
TIMELIMIT TL
Each option is associated with one or more consecutive bytes in the X.21 configuration
block. The contents of each byte or sequence of bytes determines the value of the
associated parameter.
ACCEPT CHARGES
ACCEPT CHARGES specifies whether or not ADCCP/X21 will accept charging
information from the DCE after a connection is cleared. The default value, 0, specifies
that no charging information will be accepted. If you want ADCCP/X21 to accept
charging information, set the value to 255.
Note
ADCCP/X21 will deliver call charges to your application in a DISCONNECT response only if your X.21
network provides this information. In some X.21 networks, you can issue a standing request to the
network provider: always deliver charges after a connection is cleared. In some networks, you may need
to request charging information in the selection signal sequence each time you initiate a call with a
CONNECT request.
CIRCUIT-SWITCHED
CIRCUIT-SWITCHED specifies whether the line is a leased or a circuit-switched
service. The default value is 0, which specifies leased service. If your line is connected
to a circuit-switched service, you must change the value to 255, switched service,
before issuing a START OPERATION request. The value of this parameter must be
either 0 or 255. If you specify any other value, the request is completed with a status
code 97, Error Detail 27.
3–4
CPS ACTION TABLE
The CPS ACTION TABLE is a sequence of ten bytes in the ADCCP/X21 configuration
block that specifies responses for the various types of call progress signals (CPS). The
X.21 network delivers call progress signals to the calling DTE during call
establishment, usually to indicate the reason for an unsuccessful call attempt.
ADCCP/X21 processes each incoming CPS and takes the action specified in the CPS
action table.
Table 3-2 shows the default values specified for the CPS action table. The table shows
the action that ADCCP/X21 takes on receiving a CPS from each of the classes: class 0
through class 9. The default actions correspond to the CCITT recommendation;
however, you can change any of them by issuing a WRITEREAD with a SET X.21
CONFIGURATION request.
Table 3-2. CPS Action Table
Class
Status of Call
Value
Action
0
1
In progress.
This class is not defined by CCITT.
1
3
2
Cleared by DCE because of short-term
conditions.
2
3
3
4
Cleared by DCE because of long-term
conditions.
conditions.
Cleared by DCE because of short-term
conditions.
1
conditions.
Cleared by DCE to indicate completion
of a facilities registration.
1
Wait for next event.
Clear call. Your request completes
with Status 100, Error Detail 42.
Retry. If the retry limit is exceeded,
your request completes with Status
100, Error Detail 46.
Clear call. Your request completes
with Status 100, Error Detail 42.
Your request completes with Status
Retry. If the retry limit is exceeded,
your request completes with Status
Wait for next event.
5
6
7
8
9
1
2
1
1
Each CPS consists of two digits. The first digit has a range of 0 through 9. It indicates
the class the signal belongs to and determines the response that ADCCP/X21 takes.
The second digit provides a more specific indication of the condition that generated
the signal. When a CPS of a certain type is received, ADCCP/X21 takes an action that
depends on the value of the corresponding byte in the CPS action table:
3–5
No action
ADCCP/X21 takes no action. If the DCE has cleared the call,
ADCCP/X21 completes your CONNECT request with response Status
100, Error Detail 46. If not, ADCCP/X21 waits for the next event.
To specify no action for a class of call progress signals, set the
corresponding byte to the value 1.
Retry
ADCCP/X21 automatically retries an unsuccessful call until a successful
connection is established or until a specified number of retries have been
attempted. The retry limit as well as the time interval between
successive retries are determined by ADCCP/X21 line-configuration
options. To specify retry for a class of call progress signals, set the
corresponding byte to the value 2.
Clear
ADCCP/X21 signals “clear” to the DCE and does not retry the call.
ADCCP/X21 completes your CONNECT request with an error code.
The CPS is included in the Netinfo sequence. To specify clear for a class
of call progress signals, set the corresponding byte to the value 3.
If more than one CPS is received during call establishment, ADCCP/X21 takes the
most restrictive action. Clear is the most restrictive action, then retry. No action is the
least restrictive.
NOT READY STATE
NOT READY STATE specifies whether the ADCCP/X21 signals “DTE not ready,
controlled” or “DTE not ready, uncontrolled” when entering the quiescent state. The
default value is 1, which specifies uncontrolled. Set the value to 2 if you want
ADCCP/X21 to signal “DTE not ready, controlled” when entering quiescence.
RETRY INTERVAL
RETRY INTERVAL specifies the time interval between call attempts when
ADCCP/X21 retries an unsuccessful call. This parameter can range from 0 through
65535, where each increment represents 0.01 seconds. The default value is 100 (1
second).
RETRY MAXIMUM
RETRY MAXIMUM specifies the maximum number of successive call retry attempts
before ADCCP/X21 signals an error to the host. The default value is three retries.
You can change the number of attempts to any value from 0 to 255.
DTE Time Limits
TIMELIMIT T1 through TIMELIMIT T7 specify various time limits that ADCCP/X21
uses when waiting for DCE responses during the X.21 call establishment procedure.
These parameters can take values from 0 through 65535, where each increment
represents 0.01 second. If you set the value of a TIMELIMIT parameter to 0,
ADCCP/X21 will not use that timer during call establishment.
3–6
The default settings for each time limit are set to the CCITT recommendation. You
should not need to change any of them. Table 3-3 lists the default values for these DTE
time limits.
Table 3-3. DTE Time Limit Default Values
Parameter
Default Value
Seconds
TIMELIMIT T1
TIMELIMIT T2
TIMELIMIT T3A
TIMELIMIT T3B
TIMELIMIT T4
TIMELIMIT T5
TIMELIMIT T6
TIMELIMIT T7
TIMELIMIT TL
300
2000
200
6000
200
200
200
20
2000
3
20
2
60
2
2
2
0.2
20
If one of these DTE time limits expires, your application is notified in a CONNECT
response message (Status 100, Error Detail 48-53, depending on the timer).
TIMELIMIT TL is not specified by the CCITT. ADCCP/X21 uses this time limit only
for leased lines. TL starts running when ADCCP/X21 receives a START OPERATION
request from an application. When the link enters the data transfer state (state 13), TL
is turned off. If TL expires before the link enters state 13, ADCCP/X21 completes the
START OPERATION request with an error code. The default value for TIMELIMIT
TL is 2000 (20 seconds).
3–7
Link States and The X.21 interface is defined between host data-terminal equipment (DTE) and an X.21
Transitions modem (DCE) that is connected to an X.21 network. Figure 3-2 shows the six circuits
that make up the X.21 interface between the DTE and the DCE.
Figure 3-2. X.21 Circuits
transmit (t)
control (c)
To Host
X.21
LIU
(DTE)
receive (r)
indication (i)
Modem
(DCE)
X.21
Network
signal timing (s)
byte timing (b)
014
The DTE controls the following circuits:
Transmit (t)
Control (c)
The DCE controls the following circuits:
Receive (r)
Indication (i)
Signal element timing (s)
Byte timing (b)
User data and X.21 interface control information are transmitted on circuits t, c, r, and
i. Circuits s and b transmit timing signals. Circuit b is an optional X.21 circuit that
may not be provided on all modems. It is required, however, for networks that use
selective direct call procedures.
Link states at the X.21 interface are defined by sequences of signals transmitted
between the DTE on circuits t and c and the DCE on circuits r and i. Knowing the
values of these four circuits, however, is not always sufficient to determine the state of
the link unless you also know the preceding sequence of states.
3–8
Link States for
Circuit-Switched Lines
The X.21 interface uses a special set of link states that allow the DTE to establish
circuit-switched connections with remote hosts. There are five main ADCCP/X21
interface states:
Stopped
Quiescent
Call establishment
Connected
Clearing
In addition to these five states, the ADCCP/X21 interface also has the capability to
receive call charges. Figure 3-3 shows ADCCP/X21 interface states and state
transitions on a circuit-switched connection.
Figure 3-3. X.21 Circuit-Switched Link States
Line Downloaded
Stopped
START
OPERATION
Request
Quiescent
STOP
OPERATION
Request
Request for Outgoing Call
or Incoming Call Accepted
Clearing
Clear
Call
Establishment
Connection Established
STOP
OPERATION
Request
Clear
Connected
015
3–9
Stopped State
ADCCP/X21 enters the stopped state after the CLIP has been downloaded or after a
STOP OPERATION request. In this state, ADCCP/X21 will not respond to any signals
from the DCE and will not accept any of the following requests:
CONNECT
DISCONNECT
SENDTEXT
RECEIVETEXT
MODE SET
The START OPERATION request causes ADCCP/X21 to enter the quiescent state.
Quiescent State
The quiescent state indicates that no connection with a remote station is currently
established or in the process of being established. In the quiescent state, both the DTE
and the DCE indicate whether or not they are ready to enter the call establishment
state. The link can move from the quiescent state to the call establishment state only
when both the DTE and the DCE signal “ready.”
The X.21 link enters the quiescent state either because the LIU has been started or
because the link has completed the clearing state. By default, ADCCP/X21 signals
“DTE not ready, uncontrolled.” You can alter this default setting by calling
WRITEREAD with a SET X.21 CONFIGURATION request.
ADCCP/X21 signals “not ready” to the DCE to indicate that it cannot accept an
incoming call. If an application issues a request to accept incoming calls, ADCCP/X21
changes the signal to “DTE ready.” ADCCP/X21 then remains in the ready state until
the DCE signals an incoming call or until an application issues a DISCONNECT
request.
If your application issues a request to initiate a call, ADCCP/X21 signals “DTE ready.”
If the DCE is also ready, ADCCP/X21 signals a call request and the link begins the call
establishment procedures.
DTE and DCE States During Quiescence
The link can begin call-establishment procedures only when both the DTE and the
DCE indicate “ready.” Figure 3-4 shows the six possible combinations of DTE and
DCE signals during the quiescent state.
3–10
Figure 3-4. X.21 Link States During Quiescence
DTE Not Ready,
Controlled
DTE
DTE Ready
1
DTE Ready
DCE Ready
DTE Not Ready,
Uncontrolled
DTE
t = 1, c = Off
r = 1, i = Off
DCE
Ready
14
DTE Not Ready,
Controlled
DCE Ready
24
DTE Not Ready,
Uncontrolled
DCE Ready
t = 01, c = Off
r = 1, i = Off
t = 0, c = Off
r = 1, i = Off
DCE
DCE
DCE
23
DTE Not Ready,
Controlled
DCE Not Ready
22
DTE Not Ready,
Uncontrolled
DCE Not Ready
t = 01, c = Off
r = 0, i = Off
t = 0, c = Off
r = 0, i = Off
DCE
Not
Ready
18
DTE Ready
DCE Not Ready
DTE
t = 1, c = Off
r = 0, i = Off
DTE
016
3–11
ADCCP/X21 uses circuits t and c to signal any one of three possible DTE states during
quiescence. These states are listed in Table 3-4.
Table 3-4. DTE Quiescent States
DTE State
Circuit t
Circuit c
DTE Ready
DTE Not Ready, Uncontrolled
DTE Not Ready, Controlled
t=1
t=0
t = 0101...
c = OFF
c = OFF
c = OFF
During the quiescent state, the DCE can indicate either “ready” or “not ready” on
circuits r and i. These state are listed in Table 3-5.
Table 3-5. DCE Quiescent States
DCE State
Circuit r
Circuit i
DCE Ready
DCE Not Ready
r=1
r=0
i = 0FF
i = OFF
Call Establishment State
The link can enter the call establishment state only from the quiescent state and only if
both the DTE and the DCE signal “ready.” Call-control procedures begin either when
ADCCP/X21 signals a call request or when the DCE signals an incoming call.
ADCCP/X21 Signals Call Request. The following call-control procedures depend on the
type of call requested when ADCCP/X21 signals a call request:
3–12
Normal call
Requires ADCCP/X21 to transmit a selection-signal
sequence that includes the address of the remote station.
ADCCP/X21 will transfer either full or abbreviated
addresses, according to the CCITT recommendation.
Direct call
Is used in certain X.21 networks when a predetermined
address or group of addresses has been established with the
network provider. In this case, ADCCP/X21 does not
transfer a selection-signal sequence when requesting the call.
Selective direct call
Is used in certain X.21 networks. These networks store up to
seven different addresses from which ADCCP/X21 can
select when requesting a call. The DCE must provide a byte
timing signal (b) to the X.21 LIM. ADCCP/X21 sends a
selective direct call signal to the DCE instead of a normal
call-request signal. The selective direct-call signal does not
contain a selection-signal sequence.
DCE Signals Incoming Call. If you have issued a request to accept incoming calls and the
DCE signals an incoming call, ADCCP/X21 signals “call accepted” to the DCE. After
the DCE signals “ready for data”, ADCCP/X21 considers the call established and
completes your request.
Netinfo Sequence. Depending on the facilities offered by the X.21 network, ADCCP/X21
receives various kinds of information from the DCE during connection establishment.
If requested during connection establishment, ADCCP/X21 passes the following
information to the host:
Call progress signals
If ADCCP/X21 initiates connection establishment, the DCE
may signal one or more call progress signals (CPS) to
indicate the status of the call request. Depending on its
meaning, a call progress signal may cause ADCCP/X21 to
clear the link.
Called address
In some networks, when ADCCP/X21 initiates connection
establishment, the DCE returns the address of the called line
after any call progress signals. ADCCP/X21 passes the
called address back to the host for verification.
Calling address
If ADCCP/X21 is waiting for a connection request, the DCE
may transfer the address of the calling line after signaling an
incoming call. ADCCP/X21, in turn, passes the address to
the host for identification.
Connected State
Call-establishment procedures complete successfully when a network connection is
established. The link is then in the connected state and ADCCP/X21 completes your
CONNECT request.
Note
While the link is in the connected state, it is important that your application always have a pending passive
DISCONNECT request. If the line is unexpectedly cleared, ADCCP/X21 completes this request with a
DISCONNECT response that contains the reasons for the clearing. Your application can then analyze the
Status and Error Detail codes and initiate an appropriate recovery strategy.
Once the X.21 link is in the connected state, you can set up the ADCCP protocol with
one or more remote stations and transfer frames. During the connected state, the link
is either transmitting an idle sequence or transferring frames. The idle sequence is
transmitted during the idle state, and frames are transferred during the transmit state.
These two states are defined as follows:
Idle
In this state, the DTE transmits ones or flags, depending on the SYSGEN
parameter.
Transmit
The link enters this state when the ADCCP task has frames in the transmit
queue.
3–13
If ADCCP/X21 has no frames in the output queue, the X.21 LIM transmits an idle
sequence over the link. If an application requests a data transfer or if the ADCCP
protocol requires ADCCP/X21 to send a response frame, the link enters the frame
transfer state. When the output queue is empty, the link returns to idle. Figure 3-5
shows ADCCP state changes while ADCCP/X21 is in the connected state.
Figure 3-5. ADCCP Link States During the Connected State
Successful Completion of
Call-Control Phase
Idle
Clear
Frame
Queued
for
Output
Frame
Sent
Transmit
017
Clearing State
The DTE or the DCE can initiated clearing at any time during the call control or the
connected states. After the clearing phase is complete, the link enters the quiescent
state and ADCCP/X21 signals “not ready.”
Some of the conditions that cause ADCCP/X21 to clear a connection are the following:
An application has issued a DISCONNECT or STOP OPERATION request.
A DTE time limit has expired during connection establishment.
ADCCP/X21 has detected a DCE error.
Call Charges
ADCCP/X21 provides your application with the capability to receive call charges after
the link has been cleared. When configured to accept call charges, ADCCP/X21 sets
timer T7 after clearing has been signaled, and waits for charging information to be
transmitted from the DCE.
If the DCE delivers the requested call charges before T7 times out, ADCCP/X21
completes your DISCONNECT request and enters the quiescent state. The charging
3–14
information is included in the Chargeinfo field of the DISCONNECT response
message.
If T7 times out before the DCE delivers the charging information, ADCCP/X21 enters
the quiescent state, signalling “DTE not ready.” Your DISCONNECT request
completes with a successful completion code but contains the value 0 in the
Chargeinfo Length field.
Note
Link States for Leased
Lines
For your application to received call charges, you must do the following:
1.
Request that your X.21 network provide charging information. In some X.21 networks, call charges
can be requested as a permanent facility, while in some networks, you may need to request
charges in the selection signal sequence of your CONNECT request each time you initiate a call.
2.
Configure ADCCP/X21 to accept and save call charges by issuing a SET X.21 CONFIGURATION
request in which the ACCEPT CHARGES parameter is set to 255.
3.
When the link is in the connected state, make sure your application always has an outstanding
passive DISCONNECT request, because ADCCP/X21 returns call charges only in DISCONNECT
response messages. If the link is unexpectedly cleared, and there is no passive DISCONNECT
request pending, ADCCP/X21 will save the charging information and enter the quiescent state.
ADCCP/X21 stores this information until your application retrieves it by issuing a DISCONNECT
request. If you issue a new CONNECT request, any stored charging information is lost.
The X.21 link does not require any call-control procedures for a leased circuit line.
After your application has opened the line and issued a START OPERATION request,
ADCCP/X21 signals “DTE ready.”
If the DCE is ready, ADCCP/X21 sets circuit c to ON and begins to transmit an idle
sequence. Your START OPERATION request finishes when the DCE sets circuit i to
ON and the link enters the data transfer state (state 13). The data transfer state for
leased lines is analogous to the connected state for circuit-switched connections; your
application can now set up the ADCCP protocol connections and transfer frames. In
the leased line data transfer state, ADCCP/X21 either transfers frames or transmits an
idle sequence, which are described above in the subsection “Connected State”.
Figure 3-6 shows the line link states and transitions for leased lines.
3–15
Figure 3-6. Link States and Transitions for Leased Lines
DTE
1
DTE Ready
DCE Ready
t = 1,
r = 1,
DCE
c = Off
i = Off
13 S
Send Data
13 R
Receive Data
t = Data, c = On
r = 1,
i = Off
t = 1,
c = Off
r = Data, i = On
13
Data Transfer
DCE
t = Data, c = On
r = Data, i = On
DTE
DCE Not Ready
Any State
t = 1,
c = Off
or
t = Data, c = On
r = 0,
i = Off
018
3–16
4 Writing Applications that Use
ADCCP
This section describes the tasks an application must perform to ensure successful
communication with stations on an ADCCP line. These tasks and the methods of
performing them differ slightly depending on whether:
The line is switched or leased.
The local station is a primary station, a combined station, or one or more
secondary stations.
The application is the sole user of the line.
An overview of the application tasks is also provided. The information provided
describes:
The requests to make to accomplish the task
How the task differs for different types of lines and stations
The special factors to consider if the line has multiple openers
The system procedure calls used to accomplish an application task
Detailed descriptions of ADCCP requests and responses follow the descriptions of the
application tasks
Application Tasks For an application to communicate over an ADCCP line, it must perform a specific set
of tasks. These tasks are:
Opening the line
Setting line options
Defining the station list
Preparing to receive asynchronous messages
Starting the link
Transferring data
Shutting down the link
Closing the line
The application must also be able to perform error recovery in addition to the eight
tasks involved in communicating over an ADCCP line. Refer to the CP6100 I/O Process
Programming Manual for a description of error handling and reporting, and to the
Guardian 90 Operating System Programmer’s Guide for error recovery.
4–1
Application Tasks
Opening the Line
Before an application can send or receive data over a line, it must first open a line.
To a open a line, you use the following Guardian 90 file-system procedure calls in your
application:
DEVICEINFO
OPEN
FILEINFO
NUMOUT
WRITE
AWAITIO
ABEND
SETMODE
Of these eight calls, the OPEN procedure is one that opens the line. DEVICEINFO,
FILEINFO, NUMOUT, WRITE, and ABEND are used for error handling. AWAITIO
and SETMODE handle I/O processing.
The following two examples shows how these procedure calls are used to open a line.
Descriptions of the Guardian procedures and their parameters follow the example.
This example shows how a line could be opened using he Transaction Application
Language (TAL).
Proc open^line;
begin
call DEVICEINFO(startup^msg.infile,type,reclnth);
if type.<4:9> <> 51 or type.<10:15> <> 2 then
begin
@ptr := @startup^msg.infile '<<' 1;
sbuf ':=' ptr for 9 -> @ptr;
if not type then
ptr ':=' "is not a 6100 ADCCP line." -> @ptr;
call WRITE(outfile,outbuf,@ptr '-' @sbuf);
call AWAITIO(outfile);
call ABEND;
end;
sbuf ':=' "OPEN ERROR " -> @ptr;
call OPEN(startup^msg.infile,rfnum,14);
if <> then
begin
call FILEINFO(rfnum,error);
call NUMOUT(ptr,error,10,3);
ptr[3] ':=' " on 1st open." -> @ptr;
call WRITE(outfile,outbuf,@ptr '-' @sbuf);
call AWAITIO(outfile);
call ABEND;
end
else begin
call SETMODE(rfnum,30,1);
end;
end;
4–2
Application Tasks
This example shows how a line could be opened using the C programming language.
short Open_line(open_name)
char *open_name;
/* IN - pointer to the line name string
*/
{
struct mask {
unsigned short demountable : 1;
unsigned short audited
: 1;
unsigned short undefined
: 2;
unsigned short type
: 6;
unsigned short subtype
: 6;
};
lowmem
lowmem
short
short
short
short
int
struct mask devtype;
short fname[127];
c_code = 0;
s_code = 0;
reclnth;
rfnum;
error;
/*
* The line name is converted to Guardian format, and the line is checked
* to make sure it's an ADCCP line. If it is, the line is opened and
* the file number for the line is returned to main.
*/
s_code = extfname_to_intfname(open_name,fname);
if (s_code != 0) {
printf("Error with external-to-internal filename conversion.\n");
}
DEVICEINFO(fname,&devtype,&reclnth);
if (devtype.type != 51 || devtype.subtype != 2) {
printf("%d is not a 6100 ADCCP line.\n",fname);
ABEND();
}
c_code = OPEN(fname,(short *)&rfnum,14);
if (c_code != CCE) {
FILEINFO(rfnum,&error);
printf("OPEN ERROR %d on 1st open.\n",error);
ABEND();
}
else SETMODE(rfnum,20,1);
return(rfnum);
}
Note
This subsection provides only descriptions of the procedure call parameters used in the example. These
procedure calls may have optional parameters that are not described because they are not used in the
example. Refer to the System Procedure Calls Reference Manual, Volume 1 and Volume 2, for a
complete and detailed description of these system procedure calls.
4–3
Application Tasks
DEVICEINFO Procedure
A call to the DEVICEINFO procedure obtains the configured device type and
maximum frame size of the specified line.
CALL DEVICEINFO
(
file-name
file-name
, device-type
, maximum-frame-size )
!i
!o
!o
input
INT:ref:12
is an array containing the name of the communications line whose characteristics
are to be returned. Any form of 12-word internal format file name is permitted.
device-type
output
INT:ref:1
returns the device type of the communications line specified by file-name in the
form:
.<4:9>
= Device Type
.<10:15> = Device Subtype
For an ADDCP line, the device type is be 51, and the subdevice type is 0.
maximum-frame-size
output
INT:ref:1
is the name of a one-word integer variable into which the ADCCP protocol
module places the configured maximum frame size. The maximum frame size is
originally set through the SYSGEN modifier MAXFRAME. It can be altered with a
SET CONFIGURATION request.
4–4
Application Tasks
OPEN Procedure
A call to the OPEN procedure obtains access to the specified communications line.
When OPEN finishes, a file number returns to the application process. The file
number identifies access to this communications line in subsequent file-system calls.
If an application uses multiple OPEN calls, it can issue separate AWAITIO calls to
complete each set of requests, or it may issue one AWAITIO call with a -1 instead of
the file number. If a request finishes with a nonzero condition code, the FILEINFO call
should use the file number returned by AWAITIO.
file-name
, filenum
, [flags]
, [sync-depth]
CALL OPEN (
file-name
!i
!o
!i
!i
)
input
INT:ref:12
is an array that contains the device name assigned to the particular
communications line at system generation time.
filenum
output
INT:ref:1
returns a file number that uniquely identifies this particular opening of the
specified line. All subsequent procedure calls associated with this particular line
identified by filenum refer to the line by this file number. A -1 is returned if OPEN
fails.
flags
input
INT:value
indicates the type of access to the line and the number of outstanding I/O
operations. The following table shows the bits used in this bit flag for an ADCCP
line.
—>
4–5
Application Tasks
Flag Bits
Meaning
ADCCP Setting
.<4:5>
Access mode
.<10:11>
Exclusion mode
.<12:15>
Nowait depth
Must be set to 0 for an ADDCP line to specify
READ/WRITE access.
The values for this field are specified as follows:
0 = shared
1 = exclusive
2 = reserved for use by Tandem
3 = protected
Specify shared for a line opened concurrently by more
than one process pair or a process pair that opens a
line more than once.
Specifies the number of outstanding I/O operations.
For example, if the depth is 15, the application can
issue as many as 15 calls before it must call the
AWAITIO procedure.
The window size of a line can affect the choice of the nowait depth and determine
whether the application will open the line more than once. There are several
considerations:
ADCCP allows the number of write requests per station to be equal to the
window size. It allows up to eight read requests for all stations together. The
total number of requests can therefore be much greater than the window size.
An application can set a nowait depth greater than the window size, provided
that the application does not make too many read or write requests to any
station. (ADCCP rejects a request that exceeds the limits for a station.)
If many stations are on the link or if the window size is large, a nowait depth
of 15 (the maximum per OPEN call) may not be enough to send data over the
line. A solution to this problem is to open the line more than once. For
example, use one OPEN call for read requests and another for write requests,
or use separate opens for write requests to each remote station. As many as 15
OPEN calls can be issued to the same line. If each OPEN call has a depth of
15, there can be 225 outstanding requests.
sync-depth
output
INT: value
determines whether the Guardian 90 operating system routes a new request
automatically to the backup process if the primary CP6100 process goes down.
(The alternative is to reject the request and have the application retry it.) You
should use a sync-depth of zero with 6100 ADCCP.
4–6
Application Tasks
FILEINFO Procedure
A call to the FILEINFO procedure obtains information concerning the last error for an
open line. The line must be open if you refer to the line by its file number.
CALL FILEINFO
(
[filenum]
, [error] )
filenum
!i
!o
input
INT:value
is the number returned by the OPEN call that opened the line. As an alternative,
you can supply the value -1 to request the error code associated with the most
recent line open failure.
error
output
INT:ref:1
returns the error number associated with the most recently completed operation
on the specified line. The error codes are summarized in Appendix A of this
manual.
4–7
Application Tasks
NUMOUT Procedure
The NUMOUT procedure converts unsigned integer values to their ASCII equivalents.
The result is returned right-justified in an array. Any proceeding blanks are filled with
zeros.
CALL NUMOUT
ascii-result
, unsigned-integer
, base
, width )
(
ascii-result
!o
!i
!i
!i
output
STRING:ref:*
is an array where the converted value returns. The ASCII representation is rightjustified in ascii-result[width -1]. Any preceding blanks are filled with
zeros.
unsigned-integer
input
INT:value
is the value to be converted.
base
input
INT:value
is the number base for the resulting conversion. Any number in the range 2
through 10 is valid.
width
input
INT:value
is the maximum number of characters permitted in ascii-result. Characters
might be truncated on the left side. If width is too small to contain the number,
the most significant digits are lost.
4–8
Application Tasks
WRITE Procedure
The WRITE procedure writes data from an array in the application program to an
open file.
CALL WRITE (
filenum
, buffer
, write-count )
filenum
!i
!i
!i
input
INT:value
is the number of an open file that identifies the file to be written.
buffer
input
INT:ref:*
is an array containing the information to be written to the open file specified by
filenum.
write-count
input
INT:value
is the number of bytes to be written to the file. For key-sequenced files and
relative files, 0 is illegal. For entry-sequenced files, 0 indicates an empty record.
AWAITIO Procedure
The AWAITIO procedure is used to complete a previously initiated I/O operation.
AWAITIO is used to wait for the operation to finish or to check for completion of an
operation on:
A particular file.
Any file, or to wait for a timeout to occur.
When waiting for the operation to finish on a particular file, execution of the
application process is suspended until completion occurs. A timeout is considered to
be a completion in this case. (Refer to the System Procedure Calls Reference Manual for a
description of time limits in the AWAITIO system procedure call.)
When checking for the completion of the operation, the call to AWAITIO immediately
returns to the application process, regardless of whether there is a completion or not.
(If there is no completion, an error indication returns.)
If you perform an operation using READ, WRITE, or WRITEREAD with a file opened
nowait, you must complete the operation with a call to the AWAITIO procedure.
4–9
Application Tasks
CALL AWAITIO
(
filenum )
filenum
! i,o
input,output
INT:ref:1
is the number of an open file if the AWAITIO call is to apply to a particular file.
If the AWAITIO call is to apply to any file that your application process currently
has open, filenum is -1. AWAITIO returns into filenum the file number associated
with the completed operation.
ABEND Procedure
The ABEND procedure deletes a process or a process pair and signals that the deletion
was caused by an abnormal condition. (That is, an ABEND system message is sent to
the creator of the deleted process.)
A process can use ABEND to:
Delete itself
Delete its own backup
Delete another process
The caller of ABEND must either have the same process access ID as the process it is
attempting to abend, be the group manager of the process access ID, or be the
super ID.
When ABEND executes, all open files associated with the deleted processes are
automatically closed.
CALL ABEND
All parameters for the ABEND procedure are optional. Refer to the System
Procedure Calls Reference Manual for a detailed description of this procedure.
4–10
Application Tasks
SETMODE Procedure
The SETMODE procedure is used to set device-dependent functions. For ADCCP,
you will probably only need SET MODE 30, if you need other SET MODE functions,
Refer to the System Procedure Calls Reference Manual for a complete list of the
SETMODE function codes.
A call to the SETMODE procedure is rejected with an error indication if incomplete
nowait operations are pending on the specified file.
CALL SETMODE (
filenum
, function
, [parameter-1] )
filenum
!i
!i
!i
input
INT:value
is the number returned by the OPEN call that opened the line and identifies it as
the file to receive the SETMODE function.
function
input
INT:value
is an integer value that specifies the desired SETMODE function. I/O operations
are allowed to finish in any order when function has a value of 30.
parameter-1
input
INT:value
is a subcode used in conjunction with function to further define the desired
mode setting operation. For a function value of 30, parameter-1 is as
follows:
Value
0
1
Description
I/O operations are not allowed to
complete in any order (default) .
Allow I/O operations to complete in
any order
If parameter-1 is set to 1, nowait operations do not necessarily finish in the order in
which the I/O process returns them. (Operations that finish in time for AWAITIO
to collect their output return in the order issued.)
4–11
Application Tasks
Considerations in Opening a Line
You may want your application to issue multiple OPEN procedure calls, have the
capability to handle unsolicited messages, and have multiple processes open the same
line. For each case, there are specific considerations.
Multiple OPEN Calls. If an application uses multiple OPEN procedure calls, it can issue
separate AWAITIO calls to complete each set of requests or issue one AWAITIO call
passing a -1 instead of the file number. A -1 specifies that the call to AWAITIO applies
to the oldest incomplete operation pending on each file. If a request finishes with a
nonzero condition code, the FILEINFO call should use the file number returned by
AWAITIO.
Typically, the use of multiple file numbers is restricted to data transfer. Tasks like line
configuration, link startup and shutdown, and error recovery are normally
accomplished in the scope of one OPEN call.
Unsolicited Messages. To have your application capable of receiving unsolicited
messages (that is, asynchronous messages) from the protocol tasks, your application
must have an outstanding READ call and an outstanding OPEN call. (Every READ
call must have a corresponding OPEN call.) The only other procedure calls needed on
behalf of the OPEN call dedicated to asynchronous messages would be READ,
AWAITIO, and CLOSE. If the same file number used in the READ call also appears in
other requests (that is, if there is no OPEN call dedicated to the READ call), the
application issues SETMODE 30 to the same file number used in the READ.
Multiple Processes Opening the Same Line. If multiple processes open the same line, the
following tasks should either be undertaken by only one of them or carefully
coordinated among the openers because these tasks affect all the users of the line:
Only one process should set or change the line configuration.
Only one process should define the station list, or change the condition of a station
addressed by multiple openers. (For instance, a process shouldn’t put a station in
NOPOLL condition if another process must communicate with the remote station.)
Only one process should start up or shut down the link with a remote station. If
different processes communicate with different remote stations, each process may
manage the link with its own stations; thus, only one process should be able to
stop the line.
Only one process should perform modem-control functions.
Only one process should issue the READ call to accept asynchronous messages
from ADCCP.
Only one process should issue requests to receive data from the line.
Although many processes might have to retry requests after a failure, any changes
in the mode or state of a station or the state of a link should be carefully planned
with other users of the line.
4–12
Application Tasks
Note
Setting Line Options
Simultaneous WRITEREAD calls on behalf of different opens may not have the same request ID in their
WRITEREAD buffers.
Most applications do not need to set the line-configuration options. They are defined
in the SYSGEN program. If you specify the AUTOCONF option in the SYSGEN
program, the line configuration is downloaded from the host whenever the ADCCP
protocol module is downloaded. If at some point all openers close the line,
configuration occurs again on the next OPEN call. The configuration block
downloaded at these times is the one maintained by CP6100. (Refer to the CP6100 I/O
Process Programming Manual for a description of the configuration block, and to the
System Generation Manual for CP6100 for a description of AUTOCONF.)
If you have not specified AUTOCONF or if an application requires a change in the line
configuration, the application must make a WRITEREAD call with the SET
CONFIGURATION request. The values supplied in the request do not need to match
those in the SYSGEN configuration file. The SYSGEN configuration file should,
however, contain the configuration the lines use most frequently.
The following example is a TAL procedure that uses WRITEREAD to make a request.
In this example, D is the buffer parameter in the WRITEREAD call used for the
CONFIGURATION request and response.
proc receive(filenumber,list,txtout,txtin,cmd,count,tag^value) variable; !function
int filenumber,
!value parameters
txtout,
txtin,
count,
cmd;
int(32) tag^value;
!optional value parameter
string .list;
!optional reference parameter
begin
int length;
d.msg.cmd := cmd;
!MOVE FUNCTION BYTE
d.msg.mod := 0;
!MOVE MODIFIER
d.msg.reqîd
:= cmd;
!USE FUNCTION CODE AS ID
d.msg.textôut := txtout;
!MOVE LENGTH OF TEXT FIELD IN REQUEST
d.msg.textîn := txtin;
!MOVE LENGTH OF TEXT FIELD IN RESPONSE
length := $LEN(D.basic) + txtout;
if NOT $PARAM(tag^value) then tag^value := 0D;
if $PARAM(list) then d.config.text ':=' list for txtout;
!move definelistârray
CALL WRITEREAD(filenumber,D,length, count,count^trans,tag^value);
end;
4–13
Application Tasks
The following example is a C Language function that uses WRITEREAD to make a
request. In this example, dPtr is a pointer to the the WRITEREAD buffer.
WRITEREAD is used to make the SET CONFIGURATION request and response.
void Receive(rfnum,function_code,textout,textin,length,dPtr)
short rfnum;
/* IN - file number from OPEN returned from
* Open_line.
*/
short function_code; /* IN - Request number.
*/
short textout;
/* IN - text out length for request.
*/
short textin;
/* IN - text in length for response.
short length;
struct message *dPtr;
/*
*
*/
/*
*
*
*/
IN - length of the WRITEREAD buffer.
calculated in the calling function.
IN/OUT - Points to the structured variable
that contains the request/response data
for the WRITEREAD buffer.
{
short
short
short
int
c_code = 0;
count;
count_trans;
error;
/*
* The values for the specific request are assigned to the
* structure for the request and the buffer length is set.
*/
dPtr->function =
dPtr->modifier =
dPtr->request_id
dPtr->text_out =
dPtr->text_in =
function_code;
0;
= function_code;
textout;
textin;
count = length;
c_code = WRITEREAD(rfnum,(short *)dPtr,length,count,&count_trans);
printf("Error %d occurred on WRITEREAD\n",error);
ABEND();
}
}
4–14
Application Tasks
WRITEREAD Procedure
A call to the WRITEREAD procedure initiates two separate I/O operations: a write
followed by a read. The read operation is not queued until the WRITE operation has
completed. Both operations use the same application program buffer.
CALL WRITEREAD (
filenum
, buffer
, write-count
, read-count
,[count-read]
,[tag] )
filenum
!i
!i,o
!i
!i
!o
!i
input
INT:value
is the file number returned by the OPEN call that opened the line and identifies
where the write/read is to occur.
buffer
input, output
INT:ref:*
is the name of the integer array within the application program from which the
ADCCP protocol module retrieves outgoing data (that is, the application writes
data to buffer) and into which it places the subsequent incoming data (that is,
the application reads data from buffer). The data structure of buffer should be
the structure required by the request the application is making or the response it is
receiving.
write-count
input
INT:value
specifies the number of bytes that the ADCCP protocol module retrieves from the
application buffer (that is, from the array specified by buffer.)
—>
4–15
Application Tasks
read-count
input
INT:value
specifies the number of incoming bytes the ADCCP protocol module will place in
the application buffer (that is, from the array specified by buffer.)
count-read
output
INT:ref:1
is for wait I/O only. It returns a count of the number of bytes that the ADCCP
protocol module actually placed in the application buffer.
tag
input
INT(32):value
is for nowait I/O only. The tag parameter is a double-word integer value that
you supply; it must uniquely identify the operation associated with the nowait
WRITEREAD call.
Considerations in Setting Line Options
A configuration change immediately influences action on the line. If multiple
applications use the line, be careful about any changes you make and when you make
them. To avoid problems, consider these strategies:
If applications use different values of line-configuration options, try to use
different lines for the stations they address.
Allow only the first opener to set or change the configuration, and issue the SET
CONFIGURATION request immediately after the OPEN call. Then you cannot
change options while any application has a session in progress.
See the Section 6, “Requests and Responses,” for a description of the (1) SET
4–16
Application Tasks
Defining the Station List
The application must define the station list if the link is a multipoint link or if the line
control mode is Asynchronous Balanced Mode (ABM). To define the station list, the
application makes a WRITEREAD call with the DEFINELIST request.
The following example is a TAL procedure that uses WRITEREAD to make a request.
In this example, the variable D in the WRITEREAD call is used for the DEFINELIST
request and response.
proc receive(filenumber,list,txtout,txtin,cmd,count,tag^value) variable; !function
int filenumber,
!value parameters
txtout,
txtin,
count,
cmd;
int(32) tag^value;
string .list;
begin
int length;
d.msg.cmd := cmd;
!MOVE FUNCTION BYTE
d.msg.mod := 0;
!MOVE MODIFIER
d.msg.reqîd
:= cmd;
!MOVE LENGTH OF TEXT FIELD IN RESPONSE
if NOT $PARAM(tag^value)
then
tag^value := 0D;
if $PARAM(list)
then
d.config.text ':=' list for txtout;
end;
The following example is a C Language function that uses WRITEREAD to make a
request. In this example, dPtr is a pointer to the the WRITEREAD buffer.
WRITEREAD is used to make the DEFINELIST request and response.
short rfnum;
* Open_line.
*/
*/
short textout;
*/
short textin;
short length;
/*
*
*/
/*
*
*
*/
IN - length of the WRITEREAD buffer.
{
short
short
short
int
c_code = 0;
count;
count_trans;
error;
/*
*/
dPtr->function = function_code;
dPtr->modifier = 0;
dPtr->request_id = function_code;
4–17
Application Tasks
dPtr->text_out = textout;
dPtr->text_in = textin;
count = length;
ABEND();
}
}
For an ABM link, the request provides the address of the local primary substation.
For a multipoint link, the request provides the following data for each station, which is
provide in the (69) DEFINELIST request (see the description of the (69) DEFINELIST
request in Section 6, “Requests and Responses”):
Station ID
Identifies the station and is used in all subsequent requests for the
station.
Station type
Specifies whether the local station is a primary or secondary station.
Condition
Specifies the beginning condition of the station. The condition can be
one of the following: active, NOPOLL, RNR, or ERRORSTOP.
Address
Specifies the address of the station.
If several applications use the line to communicate with different stations, each
application should define its own stations. Then the first opener can define a whole
list, giving dummy values (like NOPOLL) to stations that will be defined by other
applications. Subsequent openers can add to the list in their DEFINELIST requests;
however, the station ID in a subsequent (69) DEFINELIST request must match the ID
assigned to the station in the first (69) DEFINELIST request.
Note
If the station ID in a subsequent DEFINELIST request does not match the ID assigned in the first
DEFINELIST request, the ADCCP protocol module will return a response indicating an illegal state.
If several applications use the same stations, they must carefully coordinate the station
definitions and any changes they make. To make changes, use the (70) CHANGELIST
request in your application.
To determine the order in which stations are polled, an application makes a
WRITEREAD call with the (71) SCAN LIST request. Otherwise, the ADCCP protocol
module polls stations in order by station ID. The polling order affects all users of the
line. Therefore, if multiple applications use the line, it is best for only one application
to define the scan list.
The DEFINELIST, SCAN LIST, and CHANGELIST requests are described in detail in
the Section 6,” Requests and Responses.”
4–18
Application Tasks
Preparing to Receive
Asynchronous Messages
To receive asynchronous line quality reports from the ADCCP protocol module, an
application must issue a nowaited READ call. If the application is responsible for
establishing the modem connection (see “Starting the Link,” below), the READ call
that will handle asynchronous messages should precede the modem connection task.
In cases where there is more than one application opening the line, any other
application not connecting to the modem should issue the READ call as early as
possible, so that it is in effect by the time the modem connection occurs.
If an application opens the line more than once, it still issues only one READ call.
Unless there is an OPEN call dedicated to that READ call, the application must also
issue a SETMODE 30 call to allow the READ to finish out of sequence with other
requests. If the READ finishes, your application should always issue another one
immediately.
If an application uses SETMODE 30, operations other than the READ call can also
finish out of sequence. Almost all requests are embedded in WRITEREAD calls, and
each has a unique request ID in the buffer of the WRITEREAD call. (The application
assigns the ID, as explained in the CP6100 I/O Process Programming Manual.) When the
call finishes, the request ID is in the response buffer; thus, you can always identify the
request that finished. CP6100 and ADCCP also support tags in WRITEREAD requests.
Note
Starting the Link
Only one application should issue the READ call to accept asynchronous messages.
Starting up the link requires three or four requests, depending on whether the line is
switched or leased. The required requests are:
START
MODEM CONTROL
MODE SET
RECEIVETEXT
START
An application makes a WRITEREAD call with the START request to cause the
ADCCP protocol module to initialize its driver and to establish the modem connection
if the line is leased.
Note
The START request is unrelated to the CMI START command, but both are required for the link to be
active.
MODEM CONTROL
If the line is switched, the application makes a WRITEREAD call with the MODEM
CONTROL request, causing ADCCP to assert DTR; the appearance of DSR completes
the request.
4–19
Application Tasks
MODE SET
One or more applications make WRITEREAD calls with the MODE SET request, until
a request has accounted for every station on the station list. A single request can set
the mode for more than one station. No two requests (no two applications) should
specify the same station.
If the local station is a primary station, the request causes ADCCP to send a modesetting command (for example, SNRM) to the remote station; a UA response from the
remote station completes the request.
If the local station represents one or more secondary stations, the request causes
ADCCP to put the specified station in either of two modes:
SIM if the station must receive a SIM command from the primary.
DISC if the station must receive another mode-setting command.
The MODE SET request finishes immediately. When the local station has received and
acknowledged a mode-setting command from the remote primary station, the modesetting frame completes a RECEIVETEXT request.
If the local station is combined, the application issues a MODE SET request to get out
of DEAD mode; it may also request ADCCP to send a SABM command to the remote
station. If the remote station will not be sending a SABM command, then an
application in the local station must issue the MODE SET SABM request. (In
asynchronous balanced mode, at least one station must send a SABM command.) The
request finishes when either a UA or a SABM frame arrives from the remote station.
RECEIVETEXT
In some cases, the ADCCP protocol module delivers mode-setting commands and
responses to an application. For this reason, one application should make a
WRITEREAD call with the RECEIVETEXT request. (Only one application should
make the RECEIVETEXT request; otherwise, you cannot predict which application will
receive data.)
A primary station normally knows when the mode has been set because the
completion of a MODE SET request sets the mode. If, however, the remote station
responds with a RIM instead of a UA in response to a (67) MODE SET request,
ADCCP delivers the RIM to the application to complete a RECEIVETEXT request.
The application must then issue a MODE SET request with a SIM to initialize the
station. If the primary receives a RIM in response to the (67) MODE SET request, the
request fails and an indication is returned in the response that a RIM was received.
After acknowledging a mode-setting command for a secondary station, the ADCCP
protocol module delivers the command to one application. When a RECEIVETEXT
finishes with a notice of the mode-setting command, the application knows that the
mode-setting sequence has occurred on the line. (Thus I-frame traffic is permitted if
the sequence was a SNRM, SARM, and so on; I-frame traffic must end if the sequence
was DISC.)
4–20
Application Tasks
If a SABM arrives at a combined station that has not issued a SABM command,
ADCCP acknowledges the command and informs local applications. When a SABM
finishes a RECEIVETEXT request, the application knows that the mode-setting
sequence has occurred on the line.
Transferring Data
Once a link is established, stations are free to exchange data on the line. To send data
to a station, an application makes a WRITEREAD call with the SENDTEXT request.
To receive data, the application makes a WRITEREAD call with the RECEIVETEXT
request.
Sending Data
A SENDTEXT request specifies the station that will receive the data by its station ID.
The request indicates whether the frame is an I-frame or is of some other type; if the
mode is NRM, it also indicates whether the poll/final bit should be set (that is,
whether the frame is the last of a related sequence of I-frames). The Level 2 Protocol
queues the frame to be transmitted, and the Level 1 Protocol builds the address and
control fields (see Section 1, “Introduction to 6100 ADCCP,” for a description of the
Level 1 and Level 2 Protocols). Several factors determine when the frame is actually
placed on the line:
Frames for a given station are transmitted in the order queued.
If the local station is a secondary station in NRM, frames are transmitted only in
response to a poll.
If the local station is a TWA primary station in NRM waiting for a response to an
earlier poll, a sequence of I-frames ending with a poll bit is held until the primary
station receives the response.
If TWA transmission is in effect, frames are transmitted only when the local station
has its turn to send.
The completion of a SENDTEXT request with good request status implies that the
remote station received and acknowledged the frame.
The number of SENDTEXT requests for each application depends on the application’s
total nowait depth and the window size for each station on the link. An application
can always tell which nowait request finishes by examining the request ID in the
response buffer.
Receiving Data
A RECEIVETEXT request is used to receive data; however, unlike a SENDTEXT
request, a RECEIVETEXT request is not specific to a station. RECEIVETEXT requests
are queued, then later completed as frames arrive from any station on the link.
A completion of a RECEIVETEXT request implies that ADCCP has received the frame
and queued an acknowledgment. The response to the request identifies the station
that sent the data.
4–21
Application Tasks
An application should keep ahead of the link by posting multiple RECEIVETEXT
requests to await incoming frames. There must be at least one RECEIVETEXT request
for polling to occur.
Note
Shutting Down the Link
ADCCP can have a total of only eight pending RECEIVETEXT requests. Only one process should make
RECEIVETEXT requests; otherwise ADCCP could deliver data, and possibly control frames, to the wrong
process.
An application can shut down the link for a single station or a whole line.
No application should shut down a station or disconnect a line as long as other
applications might still want to use it.
To shut down the link for a single station, the application makes a WRITEREAD call
with the MODE SET request and puts the station in DISC mode. If the local station is a
primary station, ADCCP sends a DISC command to the remote station to disconnect it.
If the local station is a secondary station, ADCCP sends DM responses to frames that
arrive for the station. The shutdown of a secondary station can be reversed with a
mode-setting sequence. For a local station that is a primary station, the MODE SET
request to reverse the shutdown comes from an application. For a local station that is
a secondary station, a command must arrive on the line in order to reverse the
shutdown.
If you do not want a station to respond to incoming mode-setting frames, use a MODE
SET request to put the station in DEAD mode instead of in DISC mode. If you want to
shut down the link for more than one station, include a list of stations in the MODE
SET request.
If your application disconnects the stations on a line, you may also want it to
disconnect the line by dropping the DTR signal. For example, if the line is switched, it
may not be cost-effective to maintain the connection. To drop DTR, an application
makes a WRITEREAD call with the (68) MODEM CONTROL request. To connect a
line again after disconnecting it, an application must first make another (68) MODEM
CONTROL request followed by a (67) MODE SET request for the stations whose link
the application wants to restore.
An application may want to shut down the link unconditionally, without waiting for
data transfers in progress to finish. A WRITEREAD call with the (7)STOP
OPERATION request clears all of the ADCCP queues and disconnects the modem.
To start the line again, an application must begin with the (6)START OPERATION
request.
Closing the Line
4–22
An application that finishes its use of the line should issue a CLOSE call to correspond
to every one of its OPEN calls. In fact, if an application no longer needs all of its
OPEN call, it should close as many as possible, to make way for other openers. There
is a limit of 15 concurrent opens of a line.
Application Tasks
Error Recovery
There are three levels of errors reported to an application:
File-system errors
Errors unrelated to specific request
Errors related to specific requests
A file-system error is indicated when a file-system call finishes with a nonzero
condition code. To determine the error, the application uses the FILEINFO call to
return the error number.
Errors unrelated to specific requests are detected by the application when a READ call
completes. The application finds the error message in the READ buffer. Errors
reported in the READ buffer are normally line or modem problems perceived by the
protocol task. For example, the number of line errors exceed a threshold prescribed
for the line.
Errors related to specific requests are detected by the application when a WRITEREAD
call completes, and the buffer contains an error message. The application finds the
message in the second byte of the buffer; a nonzero value identifies the error that
occurred. An error in the WRITEREAD buffer signifies that the request issued by your
application was conveyed to the protocol task, but for reasons indicated in the
message, the request could not be satisfied.
The hierarchy among the different kinds of errors and the way the errors are reported
leads to an orderly error trapping and recovery procedure. The order in which an
application should handle errors is:
1.
The application calls AWAITIO to complete an earlier nowait request.
2.
If the READ or WRITEREAD finishes with a condition code other than zero, the
application calls FILEINFO to discover the error. Recommended ways to recover
from file system errors are described in Appendix A.
3.
If a READ call finished with a condition code of zero, the application examines the
buffer, which contains an error or other status message from the protocol task. If a
WRITEREAD call finishes with a condition code of zero, the application examines
the buffer, which may or may not contain an error message from the protocol task.
When a WRITEREAD call finishes with a condition code of zero, the application
request does not necessarily finish without an error. The request may, in fact,
successfully reach the protocol task, which may or may not have succeeded in
executing the request. To find out whether the desired action is taken by the protocol,
you must examine the WRITEREAD buffer; a value of zero in the status field means
that everything worked.
ADCCP error responses vary according to the request. The requests and responses
are described in the Section 6, “Requests and Responses.”
4–23
Application Tasks
In general, the responses indicate the following kinds of problems:
Hardware or resource allocation errors in a 6100/3650 CSS or 3605/6105
communications controller
Invalid request or request format
Cancellation of a pending request by another (for example, a MODE SET cancels
all pending data transfers for the station)
Station malfunctions
Modem errors.
Invalid frames received on the line
Unexpected mode-setting frames received
Sometimes recovery entails repeating the last request or making a small correction and
then repeating the request. Recovery may also involve:
Issuing new mode-setting sequences
Disconnecting a station or the line
Stopping the line until the problem has been solved
If multiple applications use the same line, you should distribute error-recovery
strategies among them to avoid contradictory or redundant requests. (Even
redundant requests can cause problems because by the time the second request
arrives, it may cause an undesirable state transition). The software running in remote
stations is also important to consider when trying to avoid contention in recovery
between stations on a link.
Error Handling and SYSGEN
Several SYSGEN parameters have an impact on error recovery. They are:
AUTOCLOSE
Determines whether opens are closed. If so, applications must close
the line and open it again to use it. For example, AUTOCLOSE is
used if the line must be downloaded because of a hardware
problem.
AUTOCONF
Determines whether the configuration block is sent from the host
after a download, replacing the current configuration; if the
application made configuration changes, it must restore them
before continuing.
AUTOLOAD
Selects whether the line is downloaded or declared down under
certain error conditions.
NOAUTOSTOP
Determines whether CP6100 makes a STOP request after closing the
opens; if so, a switched connection is lost.
For more information about these parameters, see the CP6100 I/O Programming
Manual and the System Generation Manual for CP6100. To find out how the application
4–24
Format of Requests and Responses
knows a download has occurred, see the description of file system-errors in
Appendix A of this manual.
Canceling a Request
CP6100 supports the Guardian 90 CANCEL procedure call, but ADCCP does not
support a request to cancel a specified earlier request. To cancel all pending data
transfers, flush all outstanding reads from the line, or cancel all pending data transfers
for a given station, use one of the following requests:
STOP OPERATION immediately cancels all data transfers for the line.
RECEIVETEXT has an option to flush all outstanding reads (RECEIVETEXTs)
from the line.
MODE SET, DEFINELIST, or CHANGELIST change the state of a station and
immediately cancels all data transfers in progress for the station.
Format of Requests An application makes requests and receives responses through the buffer parameter of
and Responses a WRITEREAD call. The format of the buffer for requests and responses is shown in
Figure 4-1.
Figure 4-1. WRITEREAD Buffer
String
Function, such as
Send Text
Integer
Request ID, Unique for All Pending
Requests 1 < reqid < 32767
Request ID, Same as in Request
TextOut, Size of Text Field in Bytes
Reserved, Varies by Protocol
TextIn, Number of Bytes Expected
in Response
TextIn, Number of Bytes Received
Text, Depends on
Function and Application
Text, Depends on
Function and Application
String
•
•
•
Modifier to
Function
•
•
•
Outgoing Buffer Format
(Request)
Response, Same
as Function
•
•
•
Status, OK or
Error Code
•
•
•
Incoming Buffer Format
(Reply)
012
4–25
Although the format of the buffer is the same for all requests and responses, the
meaning of the fields will vary depending on whether the data in the buffer is a
request, response, or an asynchronous response (that is, a response from the protocol
module for which there is no matching request from the application ).
Definitions of Fields in
Requests
Responses
4–26
The fields in the WRITEREAD request buffer are defined as follows:
Function
A byte that contains a number representing one request function. For
example, the number 1 represents the SET CONFIGURATION function.
Modifier
A byte that contains a number representing an option within a function.
For example, if the function is DEFINELIST, a 1 in this field calls for a
brand new station list, while a 0 calls for a change or addition to an
existing list.
Request ID
A word that contains a value from 1 through 32767, which identifies this
request among pending requests for the line. Because this ID is echoed
in the response to the request, you can always tell which request
finished, even if SETMODE 30 applies. If multiple applications use the
same line, they should assign IDs in different ranges to avoid
duplication. The ADCCP protocol module accepts duplicated Request
IDs.
Text out
A word that contains the length, in bytes, of the text field within this
request.
Text in
A word that contains the length, in bytes, of the text field in the expected
response.
Text
A string that contains additional data needed for the request. For
example, if the function is SENDTEXT, the string includes the station ID,
the setting for the poll/final bit, the type of frame to send, and the I-field
for the frame. The text out field contains the length of this field.
After a request finishes, data is returned to the WRITEREAD buffer as the response to
the request. The WRITEREAD buffer has the same structure as it did for the request;
however, some of the fields have different meanings:
Response
A byte that contains the same number that denoted the function in the
request. For example, the number 1 occurs in the response to SET
CONFIGURATION.
Status
A byte that contains a code representing normal completion or an error.
For example, the number 0 indicates normal completion; the number 70
means an invalid frame arrived on the line. Frames that have the poll bit
set are indicated in this field.
Request ID
A word that contains the same number as in the corresponding request.
Thus you can tell which request finished because this number matches
the request ID of the request that caused the response message.
Reserved
A reserved word; its contents mean nothing.
Asynchronous Responses
Text in
A word that contains the length, in bytes, of the text field in this
response. The text in field response should match the one in the request.
Text
A string that contains additional data. For example, in the response to a
FETCH CONFIGURATION request, this field contains the current values
of the line-configuration options.
In the case of an asynchronous response (a response not related to any one request),
the format of the WRITEREAD buffer is the same as for the request and response, but
with the following field definitions:
Response
A byte that contains a number representing the response. It doesn’t
match the function field of any request. For example, the number 72
denotes the LINE QUALITY response; no request ever has that number
in its function field.
Status
A byte that contains a completion code: either 0 for a normal operation or
some other number for an error. For example, ADCCP sends periodic
(72) LINE QUALITY responses in accordance with the setting of the
SYSGEN THRESHOLD parameter. In the case of a (72) LINE QUALITY
response, operation is normal and the value in the field is 0. ADCCP also
sends this response after putting a station in the ERRORSTOP condition.
In the case of an ERRORSTOP condition, a station has malfunctioned and
the value is 29.
Request ID
A word that contains only zeros.
Reserved
The contents of this word are not meaningful.
Text In
A word that contains the length, in bytes, of the text field in this
response.
Text
A string that contains data appropriate to the response. For example, in
the case of a LINE QUALITY response, it contains the line quality
information.
4–27
5 Writing Applications that Use
ADCCP/X21
This section describes the application tasks and the factors you should consider when
writing applications that communicate with stations on X.21 lines.
Application Tasks For an application to communicate over an ADCCP line, the application must perform
a specific set of tasks concerned with establishing and clearing an X.21 connection.
These tasks are:
Opening the line
Setting line parameters
Preparing to receive asynchronous messages
Starting the X.21 link
Requesting or canceling optional X.21 network facilities
Making an X.21 connection (circuit -switched or leased-line)
Preparing for unexpected disconnects of the data communications equipment
(DCE)
Performing ADCCP tasks:
Define a station list
Establish ADCCP protocol relationships
Transfer data
Shut down the ADCCP link
Clearing the X.21 connection
Closing the line
Recovering from errors
Once an X.21 connection is set up, your application can transfer and receive data with
the remote station using an ADCCP protocol. See Section 4, “Writing Applications
That Use ADCCP,” for a description of the application tasks related to setting up an
ADCCP link, establishing stations, and transferring packets. These tasks are the same
for ADCCP/X21 as they are for 6100 ADCCP.
Opening the Line Any application that wants to use the line must first open it. Just as with 6100
ADCCP, you open an ADCCP/X21 line with a call to the Guardian 90 OPEN
procedure. The parameters that you specify in the OPEN call have the same
significance for ADCCP/X21 as they do for 6100 ADCCP lines. See “Opening the
Line” in Section 4 for a description of how to open a line.
5–1
Setting Line Parameters
Setting Line Options After your application has opened the line, your application may need to set either
ADCCP line-configuration options or X.21 line options if they are not set for your
application or have changed due to a previous (1) SET CONFIGURATION or (80) SET
X.21 CONFIGURATION Request. (Your application can check the configuration by
issuing a (2) FETCH CONFIGURATION or (81) FETCH X.21 CONFIGURATION
request to the protocol module.)
Setting ADCCP Line
Options
Setting X.21 Line Options
You define ADCCP line options in the SYSGEN configuration file when you install an
ADCCP/X21 line. If you specified AUTOCONF, the line-configuration options are
automatically downloaded from the host whenever ADCCP/X21 is downloaded.
Normally, your application should not need to change any of these parameters.
However, if your application does need to change the ADCCP line configuration, your
application makes a WRITEREAD call with the (1) SET CONFIGURATION request.
See “Setting Line Options” in Section 4 for a description of how to set line options
using a WRITEREAD call.
Most of the X.21 line options are set to default values that reflect CCITT
recommendations. The options are automatically downloaded from the host when
ADCCP/X21 is loaded into the LIU. You do not specify the X.21 line options in the
SYSGEN program, nor can you change them with the Communications Management
Interface (CMI) utility. The default values in the X.21 configuration block can be
modified only by an application program; that is, your application must call
WRITEREAD with the modified values contained in a (80) SET X.21
If the ADCCP/X21 line is using a circuit-switched service, your application must issue
a WRITEREAD call with a (80) SET X.21 CONFIGURATION request in which the
CIRCUIT-SWITCHED parameter is set to 255. See Section 6, “Requests and
Responses,” for a description of the (80) SET X.21 CONFIGURATION request.
Preparing to Receive Before the X.21 link is started, your application should issue a READ call so that it can
Asynchronous receive asynchronous line quality reports. See “Preparing to Receive Asynchronous
Messages Messages” in Section 4 for a description of how your application should handle
asynchronous messages from the protocol module.
Starting the X.21 Link
5–2
After your application has opened the line and set any necessary configuration
parameters, your application must start the link. To start the link, one application
makes a WRITEREAD call with the (6) START OPERATION request. The response to
the request depends on whether the line is a switched or leased line:
Switched
ADCCP/X21 enters a quiescent state, signaling “DTE not ready.”
ADCCP/X21 immediately returns a (6) START OPERATION response.
Leased
ADCCP/X21 signals “DTE ready.” If the DCE is ready, ADCCP/X21 sets
circuit c to ON and begins to transmit an idle sequence. The (6) START
OPERATION request finishes when the DCE sets circuit i to ON and the
link enters the data transfer state (state 13).
Making an X.21 Circuit-Switched Connection
The (6) START OPERATION request and response are described in Section 6,
“Requests and Responses.”
Requesting or X.21 networks may provide optional facilities such as call charges or call redirection.
Canceling Optional X.21 users can request an optional facility for an indefinite period of time by issuing a
X.21 Network Facilities “facility registration” to the DCE. The network then provides the requested facility
until the user issues a “facility cancellation.”
To register for an optional facility, your application must issue an (82) CONNECT
request that includes a facility registration block in the Text field. The coding of this
block depends on the facilities provided by your network. To cancel an optional
facility, your application issues an (82) CONNECT request that includes a facility
cancellation block in the Text field. On completion of facility registration or facility
cancellation, ADCCP/X21 returns an (82)CONNECT response with Status 100, Error
Detail 46. To determine whether the request or cancellation was successful, your
application checks the call progress signal contained in the Text field.
Making an X.21 After your application has started the link, your application can either initiate an X.21
Circuit-Switched connection or have ADCCP/X21 wait for a call from a remote station. In either case,
Connection your application issues a WRITEREAD call with an (82) CONNECT request.
ADCCP/X21 finishes your (82) CONNECT request as soon as a connection is
established. The request may not complete for some time, however, if your
application has ADCCP/X21 waiting for an incoming call.
Your application can have only one (82) CONNECT request pending at a time.
To cancel a pending (82) CONNECT request, the application must issue a (83)
DISCONNECT request. You may want your application to do this if it must wait for
an incoming call with an outstanding passive (83) CONNECT request but needs to
initiate a connection. To cancel the passive (82) CONNECT request, your application
issues a (83) DISCONNECT request, then issues an active (82) CONNECT request.
Inserting a Selection-Signal
Sequence
The selection-signal sequence is a string of characters that your application must
include in the Text field of (82) CONNECT requests for normal outgoing calls on
circuit-switched connections. This string contains the X.21 address of the station the
application calls, along with any optional facility request codes. The ADCCP/X21
protocol module transmits the address and any other selection signals to the DCE
during call establishment.
If your network provides special facilities such as charging information or called-line
identification, your application can include requests for these facilities in the
selection-signal sequence. Check with the network provider for the coding of any
special facility request signals.
The selection signal sequence must following these syntactic guidelines:
Your application must end the sequence with a plus character (+).
Your application can use either a full or an abbreviated address signal, according
to the conventions of your network. If you insert an abbreviated address, precede
the address with a period (.).
5–3
Making an X.21 Leased-Line Connection
Your application should separate distinct facility request signals within the block
with a comma (,) and use a hyphen (-) at the end of the entire block to separate it
from the address signal that follows. If your application includes a facility request
block, it is inserted at the beginning of the selection signal sequence, before the
address signal.
The following example is a 13-byte selection-signal sequence consisting of two facility
request signals followed by a full address signal:
61,62-120302+
The first facility request signal is “61.” This is a request for charging information. The
second facility request signal, “62,” is a request for called line identification. The
address signal is “120302.” The facility request block is separated from the address
signal by a hyphen (-), and the entire selection signal sequence is terminated by a plus
(+).
For a more formal description of the selection signal sequence, refer to Annex D of the
CCITT X.21 Recommendation.
Anticipating the Netinfo
Sequence
If you want ADCCP/X21 to deliver DCE-provided information (such as call progress
signals or the called line address) to your application during connection establishment,
the (84) CONNECT request must include a value in the Text In field that is large
enough to accommodate the anticipated string. If you specify a value for Text In that
is too small, ADCCP/X21 will truncate the Netinfo sequence to fit the buffer you have
provided.
The (84)CONNECT request is described in detail in Section 6, “Requests and
Responses.”
Making an X.21 The procedures for establishing and releasing X.21 connections on leased lines are
Leased-Line easier to implement than the procedures for circuit-switched lines. On a leased line,
Connection you never need to issue an (82) CONNECT request after the line has been started
because the completion of a (6) START OPERATION request indicates that a
connection is already established. Thus, as soon as your application receives an errorfree (6) START OPERATION response, ADCCP stations can be set up and frame
transfer can begin. Similarly, to release a connection on a leased line, your application
can use the (7)STOP OPERATION request.
An application written for a circuit- switched line can be transferred to a leased line
with minimal changes. If you want to transfer such an application, you need to be
aware of the following considerations:
The value of the CIRCUIT-SWITCHED parameter in any (80) SET X.21
CONFIGURATION request must be 0 for leased service. This is the default value
for this parameter.
ADCCP/X21 is in the connected state after a (6)START OPERATION request
finishes successfully. If your application then issues a (82)CONNECT request,
ADCCP/X21 immediately returns an (82)CONNECT response with status 0,
indicating successful completion.
5–4
Performing ADCCP Tasks
If your application issues an active (83) DISCONNECT request while the leased
line is in the connected state, ADCCP/X21 releases the connection.
If a leased-line connection has been released by an (83) DISCONNECT request,
ADCCP/X21 will attempt to establish a new connection upon receiving either an
(82) CONNECT request or a (6) START OPERATION request.
If a leased line connection has been released by a (7) STOP OPERATION request,
ADCCP/X21 will attempt to establish a new connection only upon receiving of a
(6)START OPERATION request.
Preparing for During the connected phase of the X.21 link, your application should always have a
Unexpected pending request to monitor DCE disconnects. Use the passive form of the (83)
Disconnects DISCONNECT request in your application for this purpose.
Although ADCCP/X21 always monitors the communications line for clearing by the
network, an outstanding passive (83) DISCONNECT request ensures that your
application is notified immediately by ADCCP/X21 if the line is cleared.
The (83) DISCONNECT request is described in detail in Section 6, “Requests and
Responses.”
Performing ADCCP Once the X.21 link is established, your application can set up the ADCCP protocol and
Tasks exchange data with remote stations. To do this, your application needs to perform the
following tasks:
Define a station list if you want a multipoint ADCCP link on the X.21 connection.
To do this, your application issues a WRITEREAD call with a (69) DEFINELIST
request.
Establish ADCCP protocol relationships by setting the mode of each station. Your
application issues one or more (67) MODE SET requests to account for each station
on the station list.
To send data, make a WRITEREAD call with the (65) SENDTEXT request.
To receive data, make a WRITEREAD call with the (66) RECEIVETEXT request.
To shut down the ADCCP link, put the station in DISC mode by issuing a
WRITEREAD with a (67) MODE SET request.
These application tasks are the same for ADCCP/X21 as for 6100 ADCCP. See
Section 4 , “Writing Applications That Use ADCCP,” for a discussion of the tasks and
the requests that you use in your application to set up an ADCCP link and transfer
frames.
5–5
Clearing the X.21 Connection
Clearing the X.21 Your application can clear the X.21 connection at any time during the call
Connection establishment or connection phases by issuing a WRITEREAD call with an
(83) DISCONNECT request. If your application has requested ADCCP/X21 to wait for
charging information from the DCE, it must provide enough space for this information
in the (83) DISCONNECT response buffer. ADCCP/X21 delivers a maximum of 20
bytes of charging information to your application if the application requests it.
The (83)DISCONNECT request is described in detail in Section 6, “Requests and
Responses.”
Closing the Line
After an application has finished using a the line, it should issue a CLOSE call
corresponding to every one of its OPEN call. Because a line is limited to 15 concurrent
OPEN calls, an application should close any opens that it does not need.
Error Recovery You use the same error trapping and recovery strategy on an ADCCP/X21 line as you
use on a 6100 ADCCP line. ADCCP/X21 delivers a Status code in all response
messages. The Status code indicates whether or not your request finished successfully.
Response codes that refer to features of the X.21 network are described under “Status
Code Definitions” in Section 6, “Requests and Responses.” Section 4, “Writing
Applications That Use ADCCP,” describes an error recovery strategy for your
application.
5–6
6 Requests and Responses
This section describes the requests and their associated responses that you use in your
application to communicate with the ADCCP protocol module. The request and
responses are listed by function code, which is encoded in parentheses and precedes
the name of the request and response. For example the DEFINELIST request response
is listed as (69) DEFINELIST because its function code is 69. Use Table 6-1, which lists
the requests and responses in alphabetic order, to locate the request or response for
which you want a description.
Table 6-1. Requests and Responses
Function Code
Request/Response
CHANGELIST
CONNECT•
DEFINELIST
DISCONNECT•
FETCH CONFIGURATION
FETCH STATISTICS
FETCH X.21 CONFIGURATION•
LINE QUALITY*
MODE SET
MODEM CONTROL
RECEIVETEXT
SCAN LIST
SENDTEXT
SET CONFIGURATION
X.21 SET CONFIGURATION•
START OPERATION°
START TRACE
STOP OPERATION°
STOP TRACE
TRACE BLOCK*
TRANSLATE TABLE
Hexadecimal
Decimal
46
52
45
53
2
5
51
48
43
44
42
47
41
1
50
6
3
7
4
8
40
70
82
69
83
2
5
81
72
67
68
66
71
65
1
80
6
3
7
4
8
64
* Response only. An application does not make a request for these.
° This request/response has a different buffer format for ADCCP/X21
• This request/response can be used only with ADCCP/X21
6–1
(1) SET The SET CONFIGURATION request and response are used to set the values of the
CONFIGURATION configuration block in the LIU.
Request
The SET CONFIGURATION request builds the configuration block in the LIU or
replaces the values in that block. Changes take effect immediately.
The (1)SET CONFIGURATION requests is used when AUTOCONF has not been
specified in the SYSGEN program or when an application requires a change in the line
configuration. The values supplied in the SET CONFIGURATION request do not
need to match the values in the SYSGEN configuration file; however, the
configuration file should contain the line configuration used most frequently.
If more than one application will use the line, you should consider the following to
avoid problems:
If applications use different values of line-configuration options, try to use
different lines for the stations they address.
Allow only the first opener to set or change the configuration, and issue the SET
CONFIGURATION request immediately after the OPEN call. Then, you cannot
change parameters while any application has a session in progress.
To examine the current values before making a change, use the (2) FETCH
The request buffer format for is:
6–2
Function
:=
1
Modifier
:=
0
Request ID
:=
A unique value from 1 to 32767,
determined by the application
Text Out
:=
46
Text In
:=
0
Text
:=
MAXFRAME
MODE
.<0:3>
0 =
1 =
2 =
3 =
.<4:7>
1 =
2 =
3 =
AFLDn
EXTENDED
STATIONS
TRANSLATE
RNR_TIMER
XOFFSET
:Word
:Byte
BDCastON
No_RNR_Retry
No_SRNR_Retry
Option_One
NRM
ABM
ARM
:Byte
:Byte
:Byte
:Byte
:Byte
:Word
XLENGTH
:Word
POLL
:Byte
SREJ
:Byte
NOREJ
:Byte
Reserved
:Byte
TWA
:Byte
WINDOW
:Byte
SWITCHED
:Byte
HALFDUPLEX
:Byte
NOCARRFATAL
:Byte
SWINCARRIER
:Byte
SWOUTCARRIER
:Byte
FLAGIDLE
:Byte
L2RETRY
:Byte
L1RETRY
:Byte
THRESHOLD
:Word
XFERTIMER
:Word
T1TIMER
:Word
IDLETIMER
:Word
DSRTIMER
:Word
ADDRESS
:Four bytes
ABMSUPPON
:Byte
ABMIPON
:Byte
TESTFRAME
:Byte
SUPPRESSRR
:Byte
reserved
:Byte
OPTIONA
:Byte
.<0:0>
0 = Option_Two off
1 = Option_Two on
.<1:7> Reserved
OPTIONB
:Byte
.<0:7> Reserved
Table 6-2 lists a brief description and recommended value for each of the configuration
parameters (refer to the System Generation Manual for CP6100 for a detailed description
of these parameters). The recommended values listed are based on the default values
for SYSGEN; the values returned by the (2)FETCH CONFIGURATION response may
differ from these, depending on your configuration. The parameters are listed
alphabetically in Table 6-2.
6–3
Table 6-2. Descriptions of SET CONFIGURATION Parameters (Page 1 of 4)
Parameter
Byte
Offset
Recommended
Value
Range
Description
ADDRESS
36
0
1 through 254
ABMSUPPON
40
0
0, 255
ABMIPON
41
0
0, 255
AFLDn
3
1
1 through 4
DSRTIMER
34
300
0 through
32767
EXTENDED
4
0
0, 255
FLAGIDLE
23
0
0, 255
HALFDUPLEX
IDLETIMER
19
32
255
100
0, 255
0 through
32767
L1RETRY
25
3
0 through 255
L2RETRY
24
3
0 through 255
MAXFRAME
0 through 1
256
See Note 1
below.
Specifies the address value in a frame’s address field.
The address field can be from 1 to 4 bytes in length.
(See also AFLD).
Specifies that supervisory frames are sent with the P bit
set; otherwise, supervisory frames are sent with the P
bit off.
Specifies that I-frames are permitted to be sent with the
P bit set. This depends, however, on the status byte in
the (65)SENDTEXT request.
Specifies the maximum number of bytes to be found in
each frame’s address field.
Specifies the time interval that the LIU waits for a DSR
signal to appear following a DTR signal. Units are in
0.01 second (for example, 100 = 1 second).
Specifies that an extended control field is used for
frames.
Specifies that flag characters are transmitted
continuously between frames.
Specifies half-duplex or full-duplex modem operation.
Specifies the time interval between iterations of the poll
list for primary stations and between idle line RR frames
for combined stations. Units are in 0.01 second (for
example, 100 = 1 second).
Specifies the number of times the ADCCP protocol
retries transmission of a frame after the XFERTIMER
expires.
Specifies the number of times the ADCCP protocol
requests an acknowledgment when the remote station
does not respond to a link command or a poll (that is,
when the T1TIMER expires).
Specifies the maximum number of I-field (Information
field) bytes that can be sent or received over the line.
The value sets the size of the I-field only.
1 For 6100/3650 CSS - RS-232 interface: 75 through 3222
For 6105/3605 CC - RS-232 interface: 75 through 3722
For 6100/3650 CSS - X.21 interface: 75 through 1222
For 6105/3605 CC - X.21 interface: 75 through 1722
6–4
Parameter
MODE
(See Note 2 below.)
Byte
Offset
Recommended
Value
3
0 for <0.3>
1 for <4.7>
Range
Description
0, 1 through 3
Bits 0 through 3 specify RNR and polling behavior. The
values for the left nibble are:
0 Specifies that the station is a broadcast station.
This station has an address all stations can send to.
1 Specifies that ADCCP rejects all pending (65)
SENDTEXT requests. For pending SENDTEXT
requests, ADCCP returns status code 31 in the
response. For subsequent SENDTEXT requests,
ADCCP rejects them and returns status code 9 in
the response. After rejecting the requests, the
station enters LDS. A primary station sends a
DISC. A secondary station sends a FRMR.
2 Specifies that when a station is about to enter the
RNR state due to buffer constraints, all pending
(65) SENDTEXT requests are rejected. For pending
SENDTEXT requests, ADCCP returns status code
31 in the response. For subsequent SENDTEXT
requests, ADCCP rejects them and returns status
code 9 in the response. After rejecting the requests,
the station enters LDS. A primary station sends a
DISC. A secondary station sends a DM to any
frame received other than a mode setting command.
3 Specifies alternate polling behavior (Option_One).
The primary station does not send an
acknowledging RR when the secondary station
leaves the RNR state. I-frames available for the
secondary station are sent immediately, and the
primary station does not go through the poll list
before sending the frames.
Bits 4 through 7 specify the line control mode. The
value for the right nibble are:
1 Specifies normal response mode (NRM).
2 Specifies asynchronous balanced mode (ABM).
3 Specifies asynchronous response mode (ARM).
2 In SYSGEN, the line control mode is specified by NRMMODE, ABMMODE, or ARMMODE instead of MODE plus a value.
6–5
Parameter
Byte
Offset
Recommended
Value
Range
Description
NOCARRFATAL
20
0
0, 255
NOREJ
14
0
0, 255
OPTIONA
45
0
0, 255
OPTIONB
46
0
0, 255
POLL
12
1
0, 255
RNR_TIMER
(See Note 3 below.)
7
0
0 through 255
Specifies that the modem status is reported
immediately when a modem error occurs (loss of CTS
or DCD), and the link goes to the disconnect state. (See
also SWINCARRIER.)
Specifies that Reject (REJ) frames are not transmitted
and that receiving a REJ frame results in the
transmission of a Frame Reject (FRMR) frame.
Specifies that Option_Two is enabled when bit 1 of the
OPTIONA byte is set (all other bits are reserved). If bit
1 is set, the protocol module retries sending the SNRM
instead of forcing the local station into the DISC state
when a DM is received in response to a SNRM. Use
Option_Two with Token Ring controllers.
An unasigned byte in the configuration block. All bits in
this byte are reserved.
Specifies that periodic polls are sent to a remote station
when the link is idle. POLL enables a heartbeat RR
frame for ABM and ARM support at IDLETIMER
intervals when the link is idle.
Specifies a timeout for RNR in seconds. A 0 value
specifies an infinite timer.
SREJ
13
0
0, 255
STATIONS
5
1
1 through 254
SUPPRESSRR
(See Note 3 below.)
43
0
0, 255
SWINCARRIER
21
1
0, 255
SWITCHED
18
0
0, 255
SWOUTCARRIER
22
0
0, 255
Specifies that selective reject (SREJ) frames are
transmitted and received.
Specifies the maximum number of stations to be
supported and determines the space allocated for level2 control blocks. For ABM, the value is forced to 1.
Specifies that the sending of idle RR frames and that
the initial RR exchange after a mode setting sequence
are suppressed. When SUPPRESSRR is off, initial RR
exchange occurs, and idle RR occurs if POLL is on.
Specifies that the link is available for transmission when
the DCD signal is dropped. This parameter applies to
full-duplex lines.
Specifies that switched-line modem operation is
selected.
Specifies that RTS will be raised and CTS awaited
before the station begins transmission and that the RTS
and CTS signals will drop after transmission of a frame
with the poll/final bit on. This modifier applies to fullduplex lines.
3 Not configurable in SYSGEN. This parameter can be set or modified only with a SET CONFIGURATION request.
6–6
Table 6-2. Description of SET CONFIGURATION Parameters (Page 4 of 4)
Byte
Offset
Recommended
Value
T1TIMER
30 through
31
TESTFRAME
(See Note 3 below.)
Parameter
Range
Description
100
10 through
32767
42
0
0, 255
THRESHOLD
26
500
0 through
32767
TRANSLATE
6
0
0, 255
TWA
WINDOW
16
17
1
3
XFERTIMER
28
100
0, 255
See note 4
below.
10 through
32767
XLENGTH
10 through
11
0
0 through 2046
XOFFSET
8 through 9
0
0 through 2045
Specifies the time interval within which a remote station
must respond to a link command or a frame with the
poll/final bit on. The timer is started on completion of an
output frame that solicits a response from the remote
station, and is cleared on receipt of the response frame.
Units are in 0.01 seconds (for example, 100 = 1
second).
Specifies that incoming TEST frames are echoed
without passing them to the application if the station is a
secondary station. The echoing of the frames occurs in
all modes and in all connected states. If TESTFRAME
is not set, TEST frames are sent to the application and
are not echoed.
Specifies the transmit and receive frame count that
triggers the asynchronous reporting of line quality
statistics. A 0 value specifies that the
LINE_QUALITY_RSP is never sent to the ADCCP
protocol module as a result of frame counts.
Specifies that the frame I-field is translated from
EBCDIC to ASCII during transmissions between the line
and the host.
Specifies two-way alternate frame transmission.
Specifies the maximum number of I-frames sent without
receiving an acknowledgment..
Specifies a timer interval for the level-1 protocol. The
timer clocks the interval to wait until the transmission of
a frame should be complete.
Specifies the number of bytes of the I-field to translate,
starting at the offset specified by XOFFSET. A value of
0 causes all bytes from the offset to the end of the Ifield to be translated. Units are in 0.01 seconds (for
example, 100 = 1 second).
Specifies in bytes an offset into the I-field at which to
begin EBCDIC-to-ASCII translation.
3 Not configurable in SYSGEN. This parameter can be set or modified only with a SET CONFIGURATION request.
4 For basic control mode: 1 through 7
For extended control mode: 1 through 127
6–7
Response
The SET CONFIGURATION response is the expected answer to the SET
CONFIGURATION request. It indicates whether the requested changes have taken
place.
For a list of the status codes and their definitions, see “Status Code Definitions” at the
end of this section.
The response buffer format is:
6–8
Response
:=
1
Status
:=
0 if the changes have taken place,
otherwise a code for the error that
occurred
Request ID
:=
The same as in the request
Text Out
:=
0
Text In
:=
0
Text
None
(2) FETCH The FETCH CONFIGURATION request and response are used to check the current
CONFIGURATION values of the configuration block in the LIU. Your application can use the information
returned in the response to check the configuration before changing it with the
(1) SET CONFIGURATION request.
Request
The FETCH CONFIGURATION request causes the protocol module to return the
current values for the line-configuration options.
The request buffer format is:
Response
Function
:=
2
Modifier
:=
0
Request ID
:=
A unique value from 1 to 32767
Text Out
:=
0
Text In
:=
40
Text
:=
None
The FETCH CONFIGURATION response is the expected answer to the FETCH
CONFIGURATION request. It contains a copy of the configuration block stored in the
LIU. For a description of the parameters returned by the response, see Table 6-2.
Response
:=
2
Status
:=
0 if the text field contains the
configuration block, otherwise a code for
the error that occurred
Request ID
:=
Text Out
:=
0
Text In
:=
46
Text
:=
MAXFRAME
MODE SUPPORTED
AFLDn
EXTENDED
STATIONS
TRANSLATE
RNR_TIMER
XOFFSET
XLENGTH
POLL
SREJ
NOREJ
:Word
:Byte
:Byte
:Byte
:Byte
:Byte
:Byte
:Word
:Word
:Byte
:Byte
:Byte
6–9
Reserved
TWA
WINDOW
SWITCHED
HALFDUPLEX
NOCARRFATAL
SWINCARRIER
SWOUTCARRIER
FLAGIDLE
L2RETRY
L1RETRY
THRESHOLD
XFERTIMER
T1TIMER
IDLETIMER
DSRTIMER
ADDRESS
ABMSUPPON
ABMIPON
TESTFRAME
SUPPRESSRR
reserved
OPTIONA
OPTIONB
6–10
:Byte
:Byte
:Byte
:Byte
:Byte
:Byte
:Byte
:Byte
:Byte
:Byte
:Byte
:Word
:Word
:Word
:Word
:Word
:Four bytes
:Byte
:Byte
:Byte
:Byte
:Byte
:Byte
:Byte
(3) START TRACE
(3) START TRACE The START TRACE request and response is used by CMI to trace and report line
traffic and Level 1 or Level 2 Protocol events. The START TRACE request and
response use function code 3. Your application should not make a request with a
function code of 3.
The CMI TRACE facility offers all the capability of this request and response, as well
as a readable report format. For information about the facility, refer to the
Communications Management Interface (CMI) Operator Reference Manual.
6–11
(4) STOP TRACE
(4) STOP TRACE The STOP TRACE request and response is used by CMI to trace and report line traffic,
Level 1 or Level 2 Protocol events. The STOP TRACE request and response use
function code 4. Your application should not make a request with a function code of 4.
The CMI TRACE facility offers all the capability of this request and response, as well
as a readable report format. For information about the facility, consult the
Communications Management Interface (CMI) Operator Reference Manual.
6–12
Request
Note
The FETCH STATISTICS request and response are used to retrieve statistics associated
with the functioning of the line.
The FETCH STATISTICS request retrieves statistics pertaining to line quality, frames
and error counts, and signal levels. You usually use this request after receiving an
asynchronous (72) LINE QUALITY message or when you are troubleshooting a line.
This request provides more information than either the (72) LINE QUALITY response or the CMI STATUS
command.
The reset option is useful for measuring occurrences over a period of time. Reset
statistics at the beginning of the period and observe them at the end.
Function
:=
5
Modifier
:=
0 to retrieve the statistics block
1 to retrieve the statistics block and
reset counters to 0
Response
Request ID
:=
A unique value from 1 through 32767,
Text Out
:=
0
Text In
:=
26
Text
None
The FETCH STATISTICS response is the expected answer to the FETCH STATISTICS
request. It contains a block of statistics. Each statistic applies to the whole line rather
than to any specific station. Each statistic is a 16-bit integer value. Statistics are reset
only when the ADCCP module is downloaded; thereafter, counts are accumulated and
allowed to wrap around after 64K counts.
Response
:=
5
Status
:=
0 if the text field contains the statistics
block, otherwise a code for the error that
occurred
Request ID
:=
Text Out
:=
0
6–13
Text In
:=
26
Text
:=
Station ID
:Byte
The station ID is always 0 because the
counters apply to the whole line.
Status
:Byte
0 = No counter has wrapped
1 = A counter of transferred frames has
wrapped
2 = An error counter has wrapped
I-frames sent
I-frames received
:Byte
:Byte
Modeset frames sent
:Word
DISC, SIM, SNRM, SABM, SARM, SNRME,
SABME, and SARME frames count as modeset
frames.
Modeset frames received
RNR frames sent
REJ frames sent
SREJ frames sent
RNR frames received
REJ frames received
SREJ frames received
DM frames sent
DM frames received
FRMR frames sent
FRMR frames received
:Word
:Word
:Word
:Word
:Word
:Word
:Word
:Word
:Word
:Word
:Word
Input frame discarded
:Word
This counter refers to incoming frames
discarded because of incorrect addresses.
T1 timeouts
:Word
This is the number of times the T1TIMER
ran out. Each retry that ends in a
timeout counts as a separate timeout.
Transfer timeouts
:Word
This is the number of times the XFERTIMER
ran out.
Current
Current
Current
Current
Current
6–14
level
level
level
level
level
of
of
of
of
of
DTR
RTS
DSR
CTS
DCD
signal
signal
signal
signal
signal
:Word
:Word
:Word
:Word
:Word
SIO state
:Word
The value of this counter may differ from
the value of the value for DSR.
Detected CTS losses
Detected DCD losses
:Word
:Word
If you do not specify the SYSGEN
NOCARRFATAL parameter, ADCCP does not
monitor CTS or DCD, and these counters
will not mean anything.
FCS errors in input frames
Abort sequences received
Receive Overruns
:Word
:Word
:Word
A receive overrun occurs when ADCCP
cannot accept data at the rate of
the line.
No buffers for input frames
:Word
This counter is incremented every time
the controller is unable to receive a
frame. (This should not happen if RNR
is set up properly.)
Total of all link errors
This counter is the sum of the other
counters returned in the Fetch
Statistics response, starting with
counter of the input frames discarded.
(Signal levels are not included as
counters.)
.
Total frames sent and received
:Word
:Word
6–15
(6) START OPERATION
(6) START The START OPERATION request and response are used to make a modem connection
OPERATION to leased lines. For switched lines, see the (68) MODEM CONTROL request and
response.
Request for ADCCP
The START OPERATION request causes the ADCCP protocol module to initialize its
driver and to make the modem connection if the line is leased. (For a switched line,
you must use the (68)MODEM CONTROL request and response to make the
connection.)
The request finishes immediately if the line is switched. If the line is leased, ADCCP
asserts the DTR signal and waits for DSR. When DSR appears, the request finishes.
The request buffer format for ADCCP is:
Response for ADCCP
Function
:=
6
Modifier
:=
0
Request ID
:=
determined by the application.
Text Out
:=
0
Text In
:=
0
Text
None
The START OPERATION response is the expected answer to the START OPERATION
request. It indicates that ADCCP has called the driver and that DSR is present if the
line is leased.
The response buffer format for ADCCP is:
Request for X.21
Response
:=
6
Status
:=
0 if the request succeeded, otherwise a
code indicating the error that occurred
Request ID
:=
Text Out
:=
0
Text In
:=
0
Text
None
The START OPERATION request tells ADCCP/X21 to initialize its driver.
If the line is switched, ADCCP/X21 signals “DTE not ready” and completes your
application’s request.
If the line is leased, ADCCP/X21 signals “DTE ready.” When the link enters the data
transfer state, ADCCP/X21 completes your application’s request.
6–16
(6) START OPERATION
The START OPERATION request is required by ADCCP/X21 for it to enter the
quiescent state.
The request buffer format for X.21 is:
Response for X.21
Function
:=
6
Modifier
:=
0
Request ID
:=
Text Out
:=
0
Text In
:=
1 if you want error detail returned,
0 otherwise.
Text
None
The START OPERATION response is the expected answer to the START OPERATION
request. It indicates that ADCCP/X21 has initialized the X.21 driver. If the line is
leased, the link is in the quiescent ready state. If the line is switched, the LIM is
signaling “DTE not ready.”
The response buffer format X.21 is:
Response
:=
6
Status
:=
code for the error that occurred
Request ID
:=
Text Out
:=
0
Text In
:=
1 if Error Detail is supplied, 0 if not
Text
:=
Error Detail
:Byte
6–17
(7) STOP OPERATION
(7) STOP OPERATION
Request for ADCCP
The STOP OPERATION request and response are used to halt line activity and
requests. The Text In field of the STOP OPERATION request and response is defined
differently for ADCCP/X21.
The STOP OPERATION request immediately stops all line activity, aborting all
requests in progress. After the application has sent this request to the ADCCP
protocol module, only the following requests are accepted from applications:
(3) START TRACE
(4) STOP TRACE
(6) START OPERATION
This request is an extreme method of discontinuing work on the line. For information
on other means of shutting down a link, review “Shutting Down the Link” in Section
4, “Writing Applications That Use ADCCP,” and the information on starting and
stopping lines in the CP6100 I/O Process Programming Manual.
Response for ADCCP
Function
:=
7
Modifier
:=
0
Request ID
:=
Text Out
:=
0
Text In
:=
0
Text
None
The STOP OPERATION response is the expected answer to the STOP OPERATION
request. It reports that the line is now unavailable for I/O requests.
The response buffer format for ADCCP is:
6–18
Response
:=
7
Status
:=
0
Request ID
:=
Text Out
:=
0
Text In
:=
0
Text
None
(7) STOP OPERATION
Request for X.21
The STOP OPERATION request immediately stops all line activity, aborting all
requests in progress. After receiving a STOP OPERATION request, ADCCP/X21 will
not accept any of the following requests:
(65) SENDTEXT
(66) RECEIVETEXT
(67) MODE SET
(82) CONNECT
(83) DISCONNECT
The STOP OPERATION request can have serious consequences, so you should
exercise extreme caution when using it in your application to shut down a link. See
“Shutting Down the Link” in Section 3, “ADCCP/X21 Protocol Module,” and the
CP6100 I/O Process Programming Manual for information about the appropriate way to
shut down a link.
The request buffer format for X.21 is:
Response for X.21
Function
:=
7
Modifier
:=
0
Request ID
:=
Text Out
:=
0
Text In
:=
1 if you want Error Detail returned,
0 otherwise
Text
None
The STOP OPERATION response is the expected answer to the STOP OPERATION
request. It reports that the line is now unavailable for I/O requests.
The response buffer format for X.21 is:
Response
:=
7
Status
:=
Request ID
:=
Text Out
:=
0
Text In
:=
1 if Error Detail is supplied,
0 if not
Text
:=
Error Detail
:Byte
6–19
(8) TRACE BLOCK
(8) TRACE BLOCK The TRACE BLOCK response delivers a trace block to CMI; this response is not an
answer to any specific request. Your application should not make a request with a
function code of 8, which is the function code of the TRACE BLOCK response.
The CMI TRACE facility offers all the capability of this request, as well as a readable
report format. For information about the facility, consult the Communications
Management Interface (CMI) Operator Reference Manual.
6–20
(64) TRANSLATE
TABLE
Request
The TRANSLATE TABLE request and response are used to change the translation
tables for ASCII to EBCDIC and EBCDIC to ASCII.
The TRANSLATE TABLE request replaces the default translation tables (ASCII to
EBCDIC and EBCDIC to ASCII). The Text field consists of two 256-byte tables, one to
use on incoming data and one to use on outgoing data.
The ASCII-to-EBCDIC table is a list of EBCDIC values. The first value in the list is the
value to which an ASCII 0H is translated, the second is the value to which an ASCII
1H is translated, and so on. Likewise, the EBCDIC to ASCII table is a list of ASCII
values: the first value in the list is the value to which an EBCDIC 0H is translated, the
second is the value to which an EBCDIC 1H is translated, and so on.
Three line options affect the translation:
TRANSLATE indicates that incoming and outgoing data are subject to translation.
XLENGTH specifies the number of bytes to translate.
XOFFSET specifies the point at which translation should begin.
The ADCCP protocol module accepts the TRANSLATE TABLE request even if you
have not specified the TRANSLATE option. An application can start and stop
translation by using the (1) SET CONFIGURATION request.
If TRANSLATE is in effect at the time of this request, ADCCP begins using the tables
immediately. Translation affects all users of the line and should therefore be
coordinated among the applications.
Function
:=
64
Modifier
:=
0
Request ID
:=
Text Out
:=
512
Text In
:=
0
Text
:=
Table for incoming data :Array of 256 bytes
Table for outgoing data :Array of 256 bytes
6–21
Response
The TRANSLATE TABLE response indicates that ADCCP has accepted the tables and
will begin to use them as soon as the TRANSLATE line option is selected. If the
TRANSLATE option is already in effect, so are the new translation tables.
6–22
Response
:= 64
Status
:=
0 if the tables were accepted, otherwise a
code indicating the error that occurred
Request ID
:=
Text Out
:=
0
Text In
:=
0
Text
None
(65) SENDTEXT
(65) SENDTEXT
Request
The SENDTEXT request is used to transmit frames to remote stations and
acknowledge that the station has received them.
The SENDTEXT request queues a frame for transmission to a remote station. This
request makes it possible for your application to send the following types of frames:
Information frames (I-frames)
Unnumbered information frames (UI frames)
USER0, USER1, USER2, or USER3 frames
XID frames
TEST frames
The USER, XID, and TEST frame types have no special meaning in 6100 ADCCP. You
can decide their definition for your application. If the remote station is also controlled
by 6100 ADCCP, the frames you send are delivered to the remote station’s applications
and cause no protocol action beyond what you have defined.
Note
You not need to specify the address field, the control field, or the sequence numbers for an outgoing
frame. The ADCCP protocol module supplies them.
Function
:=
65
Modifier
:=
0
Request ID
:=
Text Out
:=
Number of bytes in the outgoing frame, plus
2 bytes. This count does not include the
address or control field to be added to the
outgoing frame. Also, the value in this
field may not exceed the value of the
MAXFRAME parameter.
Text In
:=
0
Text
:=
Station ID
:Byte
Use the ID of the station to which the
frame should be addressed. The
DEFINELIST request assigned the ID to
the station.
Status
:Byte
Use a value of 1 in Bit 1 if the
poll/final bit of the frame must be
set, making this the last of a related
sequence of I-frames.
6–23
(65) SENDTEXT
Indicate the frame type in Bits 1-7,
as follows:
00
64
66
74
82
87
90
92
Information
=
=
=
=
=
=
=
=
Information frame
UI frame
USER0 frame
USER1 frame
USER2 frame
XID frame
USER3 frame
TEST frame
:Array of bytes
This field becomes the I-field of the
transmitted frame. It is subject to
character code translation, as
specified in the SYSGEN program.
Response
The SENDTEXT response is the expected answer to the SENDTEXT request. It
indicates that the frame has been transmitted on the line and that the remote station
has acknowledged it.
6–24
Response
:= 65
Status
:= 0 if the operation succeeded, otherwise a
code for the error that occurred.
Request ID
:= The same as in the request
Text Out
:= 0
Text In
:= 0
Text
None
(66) RECEIVETEXT
(66) RECEIVETEXT
Request
The RECEIVETEXT request and response are used to accept frames from a remote
station.
The RECEIVETEXT request awaits incoming frames. Your application issues this
request for a primary or combined application to receive the following types of frames:
I-frames, UI frames
RIM frames
SABM or SABME frames (only if unexpected, or if the station does not issue a
SABM)
UA frames
FRMR frames
XID frames
TEST frames
You application issues this request for a secondary station to receive the following
frames:
I-frames, UI frames
SIM, SNRM, SNRME, SARM, SARME, RSET, or DISC frames
Unnumber Poll (UP) frames
RSPR frames
XID frames
TEST frames
Only one process at a time can have RECEIVETEXT requests outstanding; otherwise
one process could receive data intended for another process. ADCCP allows as many
as eight RECEIVETEXT requests to be pending.
RECEIVETEXT has a special option to flush outstanding reads from ADCCP’s queues.
This option effectively aborts any pending RECEIVETEXT requests (a step you may
want to take in the course of initialization or after a path switch). There are no
responses to any of the aborted RECEIVETEXT requests. After flushing all
outstanding reads, the request retrieves the next frame from the line.
Function
:=
66
Modifier
:=
0 to read from the line, or 255 to flush
outstanding reads
6–25
(66) RECEIVETEXT
Response
Request ID
:=
determined by application
Text Out
:=
0
Text In
:=
Ignored (ADCCP uses the maximum frame size
determined by the MAXFRAME parameter)
Text
None
The RECEIVETEXT response delivers data or other kinds of frames to the application.
The general status byte indicates whether the poll/final bit is on or off, or reports any
error that occurred during the operation. The text field status byte indicates the kind
of frame received.
If your application uses the value of 255 in the Modifier field of the RECEIVETEXT
request in order to flush all reads, the RECEIVETEXT request completes like any other
RECEIVETEXT. The response delivers an incoming frame to the application; it does
not report whether there were any requests to cancel.
Note
There is no response to a canceled RECEIVETEXT request. ADCCP assumes that the application
canceled the corresponding call or that the call finished with a path-switch error.
Response
:=
66
Status
:=
0 if the P/F bit was off, 128 if the P/F
bit was on, or a code for the error that
occurred
Request ID
:=
Text Out
:=
0
Text In
:=
I-field size of frame + 2
Text
:=
Station ID
:Byte
Identifies the station that sent the
frame
Status
:Byte
Identifies the kind of frame
(see Table 6-3)
Information
:Array of Bytes
The I-field of the incoming frame, if
received without error
Table 6-3 lists the values and their description for the status byte in the RECEIVETEXT
response.
6–26
(66) RECEIVETEXT
Table 6-3. Status Byte Values for the RECEIVETEXT Response (Page 1 of 2)
Status Byte
Value
000
64
65
66
67
68
71
72
Description
An I-frame arrived. Handle it as your application dictates. The significance of the
poll/final bit depends on whether the local station is a primary station or a secondary
station station, whether transmission is two-way alternate or two-way simultaneous,
and whether the mode is NRM or something else.
If the mode is NRM and the local station is the primary station, ADCCP polls the next
station on the scan list.
If the mode is NRM and the local station is a secondary station, ADCCP uses a
pending SENDTEXT to satisfy the poll or transmits an RR frame if no SENDTEXT is
pending. If multiple output frames are queued for the same station, ADCCP sends
them, up to and including a final bit. In ARM or ABM, the poll bit indicates a request
for synchronization in the exchange of I-frames.
A UI frame arrived. Process it as the application dictates.
If the local station is a primary station, this code indicates that a RIM arrived. Issue a
MODE SET request to send a SIM to the remote station. If the RIM is in response to
another mode-setting frame you sent, your application must send that frame again
after the SIM sequence.
If the local station is a secondary station, this code indicates a SIM arrived, indicating
ADCCP has sent an acknowledgement and awaits another mode-setting frame. Be
sure your application has a RECEIVETEXT pending to find out when that frame
arrives.
A USER0 frame arrived. Handle it as your application dictates.
If the local station is a primary station, this code indicates a DM frame arrived. The
remote station needs its mode set before it can accept other kinds of frames.
(It might have been disconnected as a result of some error.) Issue a MODE SET
request to put the station in the proper mode. If the local station is a secondary, this
code indicates that a SARM arrived and that the link is now in asynchronous
response mode.
A UP frame arrived. The local secondary station has received a poll. If SENDTEXT
requests are pending, ADCCP uses them to satisfy the poll. If not, ADCCP transmits
an RR frame with the poll bit on.
A SABM frame arrived. The link is now in Asynchronous Balanced Mode. Even if
this station sent a SABM that has not yet completed, it is now all right to make a data
transfer request.
If the local station is a primary station, this code indicates that an RD frame arrived
from a secondary station; the secondary station requests a DISC mode-setting
sequence. Issue a MODE SET call to send a DISC frame to the secondary station.
If the local station is a secondary station, this code indicates a DISC arrived from the
secondary station. This link is now in DISC mode. The local station must now await
a mode-setting frame from the primary.
6–27
(66) RECEIVETEXT
Table 6-3. Status Byte Values for the RECEIVETEXT Response (Page 2 of 2)
Status Byte
Value
74
75
76
79
80
81
82
83
87
90
91
92
6–28
Description
A USER1 frame arrived. Process it as your application dictates.
A SARME frame arrived. The link is now in Asynchronous Response Mode,
extended.
A UA frame arrived. When a UA frame arrives to complete a mode-setting sequence,
ADCCP does not deliver that frame to the application. On the other hand, if the local
station issues a SABM command and the MODE SET is completed by an arriving
SABM frame, the UA frame that may eventually arrive completes a RECEIVETEXT
request. The arrival of the UA frame indicates that the other station sent a SABM,
and the link is now in Asynchronous Balanced Mode.
A SABME frame arrived. The link is now in Asynchronous Balanced Mode.
A SNRM frame arrived. The link is now in Normal Response Mode.
If the local station is a primary, this code means a FRMR arrived on the line. If the
local station is a secondary, a RSPR arrived. The station is now DEAD and in
ERRORSTOP condition.
A USER2 frame arrived. Handle it as your application dictates.
A RSET frame arrived. The Ns and Nr counters for this station have been reset.
An XID frame arrived. ADCCP informs the application that an XID arrives.
Depending on how your network implements XID, you may need to send an XID
frame to respond to the one received (see the description of the (65) SENDTEXT
request and response in this section).
A USER frame arrived. Handle it as your application dictates.
A SNRME frame arrived. The link is now in Normal Response Mode, extended.
A TEST frame arrived. ADCCP informs the application when a TEST frame arrives.
Depending on how your network implements TEST frames, the remote station may
expect your application to take some action.
(67) MODE SET
(67) MODE SET
Request
The MODE SET request and response are used to handle mode-setting frames.
The MODE SET request causes ADCCP to send a mode-setting frame on the line to
accept a mode-setting frame if it arrives, or to disconnect a station or put it in the
DEAD mode.
If the station is a primary or combined station, this request causes ADCCP to send a
mode-setting frame to the specified remote station. The request finishes successfully
when a UA or DM frame arrives from the station. In a SABM or SABME sequence, an
arriving SABM or SABME frame also completes the request.
If a recoverable error (such as a temporary line hit) occurs during the sequence,
ADCCP tries to send its frame again. If, after the maximum number of retries
(L2RETRIES), the request does not succeed, or if the requested sequence is inconsistent
with the line configuration (for example, your application requests a SARM sequence
on a line that supports only NRM), ADCCP puts the station in DEAD mode with the
ERRORSTOP condition. (To revive the station, use a (70) CHANGELIST request.)
If the local station is a secondary station, the MODE SET request makes the station
receptive to a mode-setting frame. Unless you specify DEAD or SIM as the desired
mode, ADCCP puts the station in DISC mode, so it can respond to mode-setting
commands. (If your application specifies a mode other than DEAD, DISC, or SIM in
this case, ADCCP still puts the station in DISC mode.) If you choose DEAD, the
station does not respond to any mode-setting command. If you choose SIM, the
station transmits RIM frames until it receives a SIM.
A primary or combined station can transmit data as soon as the MODE SET request
finishes. A secondary station must first issue a RECEIVETEXT request to find out
when a mode-setting frame arrives from the primary.
Function
:=
67
Modifier
:=
0
Request ID
:=
Text Out
:=
Number of stations affected multiplied by 2
Text In
:=
Number of stations affected multiplied by 2
Text
:=
For each station affected:
Station ID
:Byte
Use the number assigned to the station
in the DEFINELIST request. Use 0 to
indicate all stations.
New mode
:Byte
0 = DEAD
1 = DISC
6–29
(67) MODE SET
2
3
4
5
6
7
8
9
Response
=
=
=
=
=
=
=
=
SIM
SNRM
SNRME
SABM
SABME
SARM
SARME
RSET (resets Nr and Ns without
changing mode; for combined
stations only)
The MODE SET response is the expected answer to the MODE SET request.
It indicates whether the operation for each station was successful.
The value in the status field for each station is 0 if the request was successful. If an
error occurred, some other value appears in the status field. The general status field
contains the code for the most recent error encountered.
If the request completed in an error for any given station, the station is in now in is
probably in DEAD mode with the ERRORSTOP condition.
Response
:= 67
Status
:=
0 if there were no errors, otherwise a code
for the most recent error
Request ID
:=
Text Out
:=
0
Text In
:=
Number of stations x 2
Text
:=
For each station named in the request:
Station ID
:Byte
Status
:Byte
0 = Completion without error, or an
error code if the request was
unsuccessful
6–30
(68) MODEM CONTROL
(68) MODEM
CONTROL
Request
The MODEM CONTROL request and response are used to connect or disconnect
modems for switched lines, and in error recovery for leased lines.
The MODEM CONTROL request connects or disconnects the modem by setting or
resetting the DTR modem signal. For switched links, the request completes only when
DSR appears.
You must use the MODEM CONTROL request to establish a switched connection.
This request can also be used in error recovery. When the MODEM CONTROL
request is used for error recovery, the line can be either leased or switched.
Function
:=
68
Modifier
:=
1 to connect the modem by setting DTR
2 to disconnect the modem by resetting DTR
Response
Request ID
:=
Text Out
:=
0
Text In
:=
0
Text
None
The MODEM CONTROL response is the expected answer to the MODEM CONTROL
request. It indicates whether the exchange of DTR and DSR signals succeeded.
Response
:=
68
Status
:=
0 if the request was successful, or an
error code if the request was unsuccessful.
Request ID
:=
Text Out
:=
0
Text In
:=
0
Text
None
6–31
(69) DEFINELIST
(69) DEFINELIST
Request
The DEFINELIST request and response are used to make changes to the station list.
The DEFINELIST request establishes, modifies, or adds to the station list (see “Polling”
in Section 2, “ADCCP Link and Station Management”). You can use this request not
only to define a whole new list but also to define new stations or change entries for
existing ones. The DEFINELIST request lets you modify the station ID, station type,
condition, and address (in contrast to CHANGELIST, which only lets you change the
condition).
This request is required in each of the following cases:
If the mode is NRM, the line is multipoint, and if the local station is a primary
station, the station list should have one entry for each remote station. The station
type should be primary because the local station is a primary station. The station
state modifier should describe the starting condition of the local station. The
address in the request should match the address of the remote station and be
consistent with the setting of the SYSGEN AFLDn parameter.
If the mode is NRM, the line is multipoint, and if the local station represents
secondary stations, the list should have one entry for each station. The station
type should be secondary. The station state modifier should describe the
condition of the local station. The stations should have different addresses,
consistent with the setting of the SYSGEN AFLDn parameter.
If the the mode is ABM, the list should have one entry. The station type should be
combined. The station state modifier should describe the condition of the local
station. The address should be that of the local primary substation. (The system
ADDRESSn parameter provides the address of the secondary substation.)
If you do not use the DEFINELIST request, the station has the following
characteristics:
The station ID is 1.
The station's type is primary.
The station state modifier is active.
The address is C1 hexadecimal.
These characteristics make the DEFINELIST request optional when the station’s mode
is NRM or ARM and the line is point-to-point. If, however, these characteristics are
not satisfactory, you can use the DEFINELIST request to change them. (Do not assign
a station ID other than 1 for a point-to-point line because other stations on the line will
not recognize the station.)
6–32
(69) DEFINELIST
Function
:=
69
Modifier
:=
0 to create a new station list and replace
the existing list, if there is one
1 to modify or add to a list, and retain
all unaffected entries
Request ID
:=
Text Out
:=
Number of stations multiplied
by (AFLDn + 3).
Text In
:=
0
Text
:=
For each station being defined
Station ID
:Byte
Use a number from 1 through 255
if the mode is NRM and the line
multipoint. Use 1 if the line
is point-to-point.
Station type
1
2
3
=
=
=
:Byte
primary
secondary
combined
The type always applies to the local
station.
Condition
0
1
2
4
=
=
=
=
Address
:Byte
Active station
NOPOLL
RNR
ERRORSTOP
:Array (1..AFLDn) of bytes
If AFLDn is 1, the address can be
any number from 1 to 254. If AFLDn is
greater than 1, each byte except the
last must have a 0 in its low-order
bit position, and the last byte must
have a 1.
6–33
(69) DEFINELIST
Response
The DEFINELIST response is the expected answer to the DEFINELIST request.
It indicates whether the station list has been successfully created or updated. If the
response status is not zero, a list probably has not been created (or no changes have
been made), and your application should issue the request again.
For list of status codes and their definitions, see “Status Code Definitions” at the end of
this section.
6–34
Response
:=
69
Status
:=
0 if all changes were made, otherwise a
Request ID
:=
Text Out
:=
0
Text In
:=
0
Text
None
(70) CHANGELIST
(70) CHANGELIST The CHANGELIST request and response are used to change the condition of stations
on a link.
Request
The CHANGELIST request changes information about one or more stations on the
link. It indicates whether each station should now be active or in NOPOLL, RNR, or
ERRORSTOP condition. (For information on each condition, see “Station States and
Transitions” in Section 2, “ADCCP Link and Station Management.”)
You use this request to temporarily disable a station, or to return a station to activity.
You can put a station in any condition. For example, you can put it in NOPOLL. If
ADCCP makes a station inactive because of a serious error, you probably should not
make it active again until after you have solved the problem.
Function
:=
70
Modifier
:=
0
Request ID
:=
Text Out
:=
Number of stations to change
multiplied by 2
Text In
:=
0
Text
:=
For each station you want to change:
Station ID
:Byte
Use the number assigned to the
station in the DEFINELIST
request. If the mode is NRM,
valid values are from 1
through 255. If the mode is ARM
or ABM, the value is 1. Use 0 to
indicate all stations.
Condition
0
1
2
4
Response
=
=
=
=
:Byte
Active station
NOPOLL
RNR
ERRORSTOP
The CHANGELIST response is the expected answer to the CHANGELIST request.
It indicates whether the station list has been successfully updated. If the response
status is not 0, probably no changes have been made in the station list.
For a list of status codes and their definitions, see “Status Code Definitions” at the end
of this section.
6–35
(70) CHANGELIST
6–36
Response
:=
70
Status
:=
0 if all changes were made, otherwise
a code for the error that occurred
Request ID
:=
Text Out
:=
0
Text In
:=
0
Text
None
(71) SCAN LIST
(71) SCAN LIST The SCAN LIST request and response are used to define the polling order for
secondary stations.
Request
The SCAN LIST request defines an alternative polling order for secondary stations.
By default, ADCCP polls stations in order of increasing station ID. This request is
valid only if the local station is the primary station on a multipoint NRM line.
The SCAN LIST request takes effect immediately, even interrupting a cycle in
progress. It lasts until the next:
SCAN LIST request
DEFINELIST request that creates a new list
SET CONFIGURATION request that changes the number of stations allowed
The same station ID can appear more than once in the SCAN LIST request. When that
happens, the station is polled more often than other stations on the link.
Function
:=
71
Modifier
:=
0
Request ID
:=
Text Out
:=
Number of entries in the list
Text In
:=
0
Text
:=
Scan list
:Array of bytes
List the stations in the order in which
you want them to be polled. Use the
numbers assigned to the stations in the
DEFINELIST request.
6–37
(71) SCAN LIST
Response
The SCAN LIST response is the expected answer to the SCAN LIST request.
It indicates whether the scan list has been successfully updated. If the response status
is not a 0, assume that the new list has not taken effect.
6–38
Response
:=
71
Status
:=
0 if the new list is in effect, otherwise a
Request ID
:=
Text Out
:=
0
Text In
:=
0
Text
None
(72) LINE QUALITY
(72) LINE QUALITY The LINE QUALITY response is not an answer to any specific request. ADCCP sends
it to an application for one of three reasons:
The number of frames sent and received exceeds the value of the SYSGEN
THRESHOLD parameter.
An error occurs that causes ADCCP to place a station in the ERRORSTOP
condition. An example of such an error is when the number of retries specified by
L2RETRY is exhausted.
One or more link error counters have wrapped around to zero. (See the
(5) FETCH STATISTICS request and response.)
Response
:=
72
Status
:=
0
Request ID
:=
0
Text Out
:=
0
Text In
:=
6
Text
:=
Station ID
:Byte
If a station was disabled, this byte
contains the station ID. Otherwise, the
value is 0.
Status
:Byte
This byte contains the code for the error
that caused the station to be disabled.
For a list of status codes and their
definitions, see “Status Code
Definitions” at the end of this section.
Total frames sent and received
:Word
Total link errors
:Word
The description of the FETCH STATISTICS
response lists the link errors.
6–39
(80) SET X.21 The SET X.21 CONFIGURATION request and response are used to modify the X.21
CONFIGURATION configuration block in the LIU.
Request
The SET X.21 CONFIGURATION request replaces values in the X.21 configuration
block in the LIU. Until you issue this request, ADCCP/X21 uses the default
configuration values. You can issue a SET X.21 CONFIGURATION request at any
time, but ADCCP/X21 does not implement any changes until the option is used.
To examine the current values before making a change, use the (81) FETCH X.21
Function
:=
80
Modifier
:=
0
Request ID
:=
Text Out
:=
34
Text In
:=
1 if you want error detail returned,
0 otherwise
Text
:=
CIRCUIT-SWITCHED
NOT READY STATE
ACCEPT CHARGES
RETRY MAXIMUM
RETRY INTERVAL
CPS ACTION TABLE
TIMELIMIT T1
TIMELIMIT T2
TIMELIMIT T3A
TIMELIMIT T3B
TIMELIMIT T4
TIMELIMIT T5
TIMELIMIT T6
TIMELIMIT T7
TIMELIMIT TL
:Byte
:Byte
:Byte
:Byte
:Word
:Ten bytes
:Word
:Word
:Word
:Word
:Word
:Word
:Word
:Word
:Word
See “X.21 Line Configuration Options” in Section 3, “ADCCP/X21 Protocol Module,”
for a description of the parameters specified in the text field of the SET X.21
CONFIGURATION response .
6–40
Response
The SET X.21 CONFIGURATION response is the expected answer to the SET X.21
CONFIGURATION request. It indicates whether the requested changes have taken
place.
Response
:=
80
Status
:=
0 if the changes have taken place,
occurred.
Request ID
:=
Text Out
:=
0
Text In
:=
1 if error detail is supplied,
0 if not
Text
:=
Error detail
:Byte
6–41
(81) FETCH X.21 The FETCH X.21 CONFIGURATION request and response are used to retrieve the
CONFIGURATION current values of the X.21 configuration block in the LIU.
Request
The FETCH X.21 CONFIGURATION request retrieves the current values for X.21
configuration parameters. For information about the parameters, see“X.21 Line
Configuration Options” in Section 3, “ADCCP/X21 Protocol Module”.
Response
Function
:=
81
Modifier
:=
0
Request ID
:=
Text Out
:=
0
Text In
:=
34
The FETCH X.21 CONFIGURATION response is the expected answer to the FETCH
X.21 CONFIGURATION request. The format of this response depends on whether the
request completes successfully.
If no error occurs, the FETCH CONFIGURATION response contains a copy of the X.21
configuration block stored in the LIU.
6–42
Response
:=
81
Status
:=
0
Request ID
:=
Text Out
:=
0
Text In
:=
34
Text
:=
CIRCUIT-SWITCHED
NOT READY STATE
ACCEPT CHARGES
RETRY MAXIMUM
RETRY INTERVAL
CPS ACTION TABLE
TIMELIMIT T1
TIMELIMIT T2
TIMELIMIT T3A
TIMELIMIT T3B
TIMELIMIT T4
TIMELIMIT T5
TIMELIMIT T6
TIMELIMIT T7
TIMELIMIT TL
:Byte
:Byte
:Byte
:Byte
:Word
:Ten bytes
:Word
:Word
:Word
:Word
:Word
:Word
:Word
:Word
:Word
If an error occurs while your application is fetching the X.21 configuration block, the
ADCCP/X21 protocol module returns the following response buffer:
Response
:=
81
Status
:=
Error code
Request ID
:=
Text Out
:=
0
Text In
:=
1 if error detail is supplied,
0 if not.
Text
:=
Error detail
:Byte
6–43
(82) CONNECT
(82) CONNECT
Request
The CONNECT request and response are used to accept incoming calls and request
outgoing calls. This request and response works only with the ADCCP/X21 protocol
module.
The CONNECT request has different functions. Depending on the values you place in
the request Modifier and the Text field, a CONNECT request can indicate any one of
the following types of connections:
Readiness to accept an incoming call
A request for a normal outgoing call
A request for a direct outgoing call
A request for a selective direct outgoing call
A request for facility registration or facility cancellation
Accepting an Incoming Call
When the CONNECT request is used to accept an incoming call, it causes
ADCCP/X21 to signal “DTE ready” and wait for a call to arrive from the DCE. This is
called a passive CONNECT request because ADCCP/X21 does not actively initiate a
connection.
The request buffer format for accepting and incoming call is:
Function
:=
82
Modifier
:=
1
Request ID
:=
Text Out
:=
8
Text In
:=
10 + length of DCE-provided information
Text
:=
Reserved for ADCCP
:Eight bytes
Set these bytes to 0
Note
6–44
If your application has been waiting for an incoming call and now wants to initiate a connection, you must
first cancel the pending passive CONNECT request before ADCCP/X21 will accept a new active
CONNECT request. To cancel a CONNECT request, issue a DISCONNECT request.
(82) CONNECT
Normal Outgoing Call
When the CONNECT request is used for a normal outgoing call, it causes
ADCCP/X21 to initiate a normal call establishment procedure.
The request buffer format for a normal outgoing call is:
Function
:=
82
Modifier
:=
2
Request ID
:=
Text Out
:=
9 + length of selection signal sequence
Text In
:=
10 + length of DCE provided information
Text
:=
Reserved for ADCCP
:Eight bytes
Set these bytes to 0
Selection signal length
:Byte
This value can range
from 0 through 127
Selection signal sequence
:Character
string
Direct Call
When the CONNECT request is used to make a direct call, it causes ADCCP/X21 to
initiate a direct call. The request format for this call is the same as that for a normal
call request, except that your application does not include an address in the selection
signal sequence.
The request buffer format for a direct call is:
Function
:=
82
Modifier
:=
2
Request ID
:=
a unique value from 1 to 32767,
Text Out
:=
9
Text In
:=
10 + length DCE-provided information
Text
:=
Reserved for ADCCP
:Eight bytes
Set these bytes to 0.
0
:Byte
6–45
(82) CONNECT
Selective Direct Call
When the CONNECT request is used to make a selective direct call, it tells
ADCCP/X21 to initiate a selective direct call. Your application must include the
selective direct call number in the text field.
The request buffer format for a selective direct call is:
Function
:= 82
Modifier
:=
3
Request ID
:=
Text Out
:=
9
Text In
:=
10 + length of DCE-provided information
Text
:=
Reserved for ADCCP
:Eight bytes
Selective Direct Call Number
:Byte
This number ranges from 1 through 7
Facility Registration and Facility Cancellation
When the CONNECT request is used for Facility Registration, it invokes special
facilities, such as call redirection, on networks that provide them. When the
CONNECT request is used for facility cancellation, it cancels a previously invoked
registration.
Neither of these types of CONNECT requests establishes a connection. The DCE
completes the request with a call progress signal, then signals ”clear.” The call
progress signal indicates whether the request was successful. ADCCP/X21 then
completes your facility registration or cancellation request with a CONNECT response
containing Status 100, Error Detail 46. The Netinfo sequence contains the call progress
signal that was returned by the DCE.
6–46
Function
:=
82
Modifier
:=
2
Request ID
:=
Text Out
:=
9 + length of Registration/Cancellation
block
Text In
:=
10 + length of Netinfo sequence
Text
:=
Reserved for ADCCP
:Eight bytes
(82) CONNECT
Registration/Cancellation
Block Length
:Byte
This value can range from 2 through 127
Registration/Cancellation
Block
:Character
string
The coding of this block depends on the
facilities provided by the network
Response
The CONNECT response is the expected answer to the CONNECT request. This
response usually indicates the outcome of an attempted connection. A value of 0 in
the Status field indicates a successful connection; any other value in the Status field
indicates why a connection was not successful.
When the associated CONNECT request was used for facility registration or
cancellation, the CONNECT response normally returns a Status 100, Error Detail 46,
and includes a call progress signal in the Netinfo sequence. The call progress signal
indicates whether the request was successful.
Response
:=
82
Status
:=
0 indicates a successful connection,
occurred
100 for normal facility registration or
cancellation responses
Request ID
:=
Text Out
:=
0
Text In
:=
Text
:=
Used by ADCCP
:Eight bytes
Error detail
:Byte
This code provides a more specific
indication of the error if the status
field has a value other than zero.
Normal facility registration or
cancellation responses finish with the
value 46 in this field.
Netinfo length
:Byte
This value indicates the length of the
information received from the DCE.
The Netinfo Sequence that follows may
6–47
(82) CONNECT
be smaller if you haven’t provided
enough buffer space in the Text In
field.
Netinfo sequence
:Array of bytes
This sequence includes information
provided by the DCE such as the remote
station address. When this response
completes a facility registration or
cancellation, this sequence contains the
call progress signal that was returned by
the DCE.
6–48
(83) DISCONNECT
(83) DISCONNECT The DISCONNECT request and response are used to clear an X.21 connection. This
request and response work only with the ADCCP/X21 protocol module.
Request
The DISCONNECT request has two uses. Depending on the value you place in the
request modifier, your request indicates the type of disconnect:
Active
An active disconnect is a request to clear the connection. ADCCP/X21
cancels all pending connect and passive disconnect requests, and signals
clear to the DCE.
Passive A passive disconnect is a request to monitor for disconnects. ADCCP/X21
does not complete a passive disconnect request unless: (1) the DCE signals
clear, (2) ADCCP/X21 has detected a DCE error and cleared the connection,
or (3) the passive disconnect was canceled by a STOP OPERATION request
or a new DISCONNECT request.
If you request ADCCP/X21 to deliver the network charges in the DISCONNECT
response, ADCCP/X21 waits for the charges from the DCE after the call is cleared.
The value in the TIMELIMIT T7 configuration parameter determines the amount of
time ADCCP/X21 waits.
You can cancel a passive disconnect request by issuing an active disconnect request to
the same line.
Function
:= 83
Modifier
:=
1
to indicate passive disconnect
2
to indicate active disconnect
Request ID
:=
Text Out
:=
8
Text In
:=
10 + expected length of Netinfo sequence
Text
:=
Reserved for ADCCP
:Eight bytes
6–49
(83) DISCONNECT
Response
The DISCONNECT response is the expected answer to the DISCONNECT request.
Response
:=
83
Status
:=
0 indicates disconnected, otherwise a code
indicating why your request was rejected
Request ID
:=
Text Out
:=
0
Text In
:=
Text
:=
Used by ADCCP
:Eight bytes
Contains short-hold mode and
line-state information
Error detail
:Byte
Chargeinfo length
:Byte
This value ranges from 0 through 20.
It indicates the length of the call
charge sequence actually received
from the DCE. The charging
information that follows may be
truncated if you haven’t provided
enough buffer space in the Text In
field.
Charging information
6–50
:Byte array
Status Code This subsection lists the status codes the ADCCP protocol module returns to
Definitions applications in response to requests.
Table 6-4 lists the status codes that indicate a request was successful.
Table 6-4. Status Codes for Successful Requests
Status
Code
Next State
Definition
0
128
Request Specific
READY
The request was successful.
The arriving frame had the poll/final bit on. See the description of
(66) RECEIVETEXT in this section for an explanation.
The status codes listed in Table 6-5 suggest hardware or resource allocation errors in
3650/6100 family controllers.
Table 6-5. Status Codes Indicating Resource or Allocation Errors
Status
Code
Next
State
1
Definitions
Recovery
Same
There was a bad sequence number in a frame in route
from a controller to an LIU.
2
Same
The LIU received the wrong sequence of frame types from
the controller.
3
Same
The LIU received an invalid frame type from the controller.
4
Same
There is no room for the request frame on the LIU.
5
Same
6
Same
An addressing error (invalid task ID) has occurred in the
3650/6100 family controller, suggesting that an expected
piece of software is not running there. Possibly the LIU or
one of the microcode files is faulty.
A resource shortage occurred in the 3650/6100 family
controller, thwarting communication between tasks.
This error is usually temporary; try the request
again. If the error persists, call your Tandem
representative.
This error is usually temporary; try the request
again. If the error persists, call your Tandem
representative.
Try to issue the request again. If the error
persists, call your Tandem representative.
Wait for traffic on the line to subside, and try
to issue the request again. DO NOT
REPEAT THE REQUEST OR MAKE ANY
OTHER REQUEST RIGHT AWAY. If the
problem persists or occurs frequently,
consider making the changes described in
Section 2, “ADCCP Link and Station
Management” in “Station and Data Capacity
on Links.”
Locate the software that is not running and
start it. Replace the LIU or replace the
microcode file(s). Call your Tandem
Representative for assistance.
Try the request again. If the problem persists,
call your Tandem representative.
6–51
Table 6-6 lists codes that usually indicate an invalid request or format.
Table 6-6. Status Codes Indicating Invalid Request or Format
Status
Code
Next
State
8
Same
9
Same
10
Same
11
Same
12
Same
13
Same
14
Same
15
Same
A value in the Text field is invalid. For example, you issue
a SENDTEXT request and the bits that identify the frame
type do not have a meaningful value.
18
Same
Insufficient resources to perform function.
6–52
Definition
Recovery
Too many of these requests are already queued. For
example, ADCCP already has eight RECEIVETEXT
requests outstanding, or the number of SENDTEXT
requests for a station already matches the window size.
The request is invalid for the current station state. For
example, SENDTEXT is valid only in the information
transfer state (ITS).
Wait for a pending request to finish, and then
try your request again.
The value in the Function or Modifier field of the request is
invalid. For example, you specified 25 as a function code,
or you made a DEFINELIST request with a modifier of 3.
Replace the incorrect values with correct ones.
The request ID is not in the range 1 through 32767.
The value in the Text Out field does not match the actual
length of the Text field, or is inconsistent with the request.
For example, you specified 256 in the TRANSLATE TABLE
request.
The value in the Text In field is not sufficient for the
operation or is inconsistent with the request. For example,
the value you specified in the FETCH STATISTICS request
is not large enough to accommodate the statistics array.
A station ID you specified is undefined or invalid. The only
valid IDs are those assigned in the last DEFINELIST
request.
Make the requests necessary to reach the
desired state. Review the description of
station states in “Station States and
Transitions” in Section 2, “ADCCP Link and
Station Management.”
Replace the incorrect values with correct
ones.
Replace the request ID with a value in the
range 1 through 32767.
Replace the incorrect value with a correct
one.
Replace the value in the Text field with one
large enough for the operation.
Omit or replace the invalid ID. If the line is
multipoint, numbers in the range 1 through
255 are valid; if the line is point-to-point, only
the number 1 is valid.
Replace the incorrect value with a correct
one.
Reconfigure the line. (For example, change
the window size or frame size.)
Table 6-7 lists status codes that indicate a request failed or was cancelled.
Table 6-7. Status Codes Indicating a Failed or Cancelled Request
Status
Code
Next
State
24
Definition
Recovery
STOPPED
An application issued a STOP OPERATION request. All
stations are now DEAD and all pending requests aborted.
25
Requestspecific
26
Requestspecific
27
READY/DISC
28
DISC
An application issued a MODE SET request to this station
or received a mode setting command from the remote
station. Pending data transfers for the station are
aborted. The new station state and mode depend on the
MODE SET request; for example, a MODE SET SNRM
puts the station in ITS and Normal Response Mode.
The remote primary station sent a mode-setting frame to
this station. Pending data transfers for the station are
aborted. The new station state and mode depend on
which mode-setting frame arrived.
A request failed, even after the allowed number of retries.
The state of the station is unchanged. This error is
typically reported in connection with a MODE SET DISC
request.
A request failed, even after the allowed number of retries.
The station is DEAD and in ERRORSTOP condition.
To recover, make the requests described in
“Starting the Link” in Section 4, “Writing
Applications That Use ADCCP.”
Recovery from this condition is applicationdependent. The application may purposely
issue MODE SET to cancel requests.
29
Requestspecific
DISC
DISC
30
31
A new request replaced the one in progress.
RNR condition lasted too long.
SENDTEXT received as a response and No_RNR_Retry
option selected or No_SRNR_Retry is selected and the
local sent an RNR.
Recovery from this condition is applicationdependent, and recovery probably requires
waiting for an action from the primary station.
Try the request again. The problem is with
the other station.
You can use CHANGELIST to revive the
station, but probably should not until you have
checked the station for a possible
malfunction. It is also possible that
L2RETRIES should have a greater value.
None. This is a warning.
Application dependent.
6–53
Table 6-8 lists status codes that indicate a fatal modem error occurred.
Table 6-8. Status Codes Indicating a Fatal Modem Error
Status
Code
Next
State
32
Definition
Recovery
STOPPED
The modem reset the DSR signal, disconnecting the
line.
33
STOPPED
34
STOPPED/same
The modem reset the transmit clock, disconnecting
the line.
The modem reset the DCD signal unexpectedly.
Try to connect the line again, using START or
MODEM CONTROL. If the problem persists
or occurs frequently, test the modem for a
possible disorder. You might also use
FETCH STATISTICS to find out the state of
the DTR signal; there could be something
wrong on the LIU side of the interface.
Test the modem for a possible disorder.
35
STOPPED/Same
The modem reset the CTS signal unexpectedly.
36
Same
The modem did not assert DSR within the expected
time interval, or did not drop DSR within the expected
time interval.
39
Same
DSR came up (V.25 only - V.25 terminated).
6–54
If you specified the NOCARRFATAL option,
the line is now disconnected; if not, the line
state has not changed. Test the local and
remote modems for for possible disorders.
You can also use FETCH STATISTICS to find
out the state of the RTS signal; there could be
something wrong on the LIU side of the
interface.
If you specified the NOCARRFATAL option,
the line is now disconnected; if not, the line
state hasn’t changed. Test the local and
remote modems for possible disorders. You
might also use FETCH STATISTICS to find
out the state of the RTS signal; there could be
something wrong on the LIU side of the
interface.
The time interval is determined by the
DSRTIMER parameter. Possible causes for
this problem are a modem malfunction, a
problem on the LIU side of the interface, (for
example, a bad DTR signal), or a DSRTIMER
value that is too low for the application. See
the description of DSRTIMER in Section 1,
“Introduction to 6100 ADCCP.”
The modem is not configured for V.25.
Table 6-9 lists codes that report errors in incoming frames.
Table 6-9. Status Codes Indicating Frame Errors
Status
Code
Next
State
40
DISC
41
DISC
42
DISC
43
DISC
44
DISC
45
READY
Definition
Recovery
The remote station did not respond to an information
frame. This error is typically reported in a SENDTEXT
response.
An input frame exceeded the maximum length defined
for the line. The station state does not change. As
much of the frame as possible is delivered to the
application.
An input frame had an invalid C-field; the station is in
DISC mode. There is either a configuration problem or a
remote station malfunction.
An I-field was present in an input frame that should not
have contained one. For example, there was an I-field in
a mode-setting frame. The station is in DISC mode.
There is either a line problem or a station problem.
The Nr value in an incoming frame acknowledged a
frame that had not yet been sent.
Specified Poll Cycles done.
Change the value of MAXFRAME.
With a configuration problem , you will see
effects on other stations; use FETCH
STATISTICS or LINE QUALITY to investigate
the problem. If the remote station station is
malfunctioning, be careful about
reestablishing the link before the solving the
problem with the remote station.
Use the same recovery procedure as for
status code 42.
Use the same recovery procedure as for
status code 42.
None. This is an indication only.
6–55
There are many status codes that appear only in the RECEIVETEXT response. It is
therefore crucial for an application to have outstanding RECEIVETEXT requests, not
only to capture incoming data but also to receive error reports. Table 6-10 lists these
errors.
Table 6-10. RECEIVETEXT Responses
Status
Code
Next
State
64
65
66
67
68
69
70
71
72
73
74
75
76
Same
DISC
Same
DISC
Same
Same
Same
DISC
DISC
Same
Same
DISC
Requestspecific
Same
Same
DISC
NRM
DISC
Same
DISC
Same
Same
Same
Same
Same
Same
Same
NRM
Same
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
6–56
Description
UI frame received
RIM-Primary, SIM-Secondary
USER0 frame received
DM-primary, SARM-secondary
UP frame received, secondary
Invalid frame received
SABM frame received, secondary
Remote initialized DISC sequence
SARME-Secondary only
UA frame received, primary
SABME received, Secondary
Received by Secondary Only
FRMR-Primary, RSPR-Secondary
RSET frame received, Secondary
XID frame received
Received by Secondary Only
TEST frame received
X.21 messages use a special set of status codes that describe conditions related to the
X.21 call setup and clearing procedures. These codes are listed and defined in
Table 6-11.
Table 6-11. Status Codes and Error Details for X.21 (Page 1 of 2)
Status
Code
Error
Detail
0
96
16
17
97
24
25
26
27
98
99
32
33
Definition
The request was successful.
ADCCP/X21 rejected your request because an illegal count was specified.
Invalid Text Out count.
Invalid Text In count.
Your request was rejected because there was an illegal value in the request
buffer.
Invalid function code.
Invalid function modifier.
Invalid request ID.
Invalid text value. One of the text field parameters had an illegal value.
Duplicate request. Rejected by ADCCP/X21.
Request aborted due to a STOP or DISCONNECT request.
Canceled by DISCONNECT.
Canceled by STOP 100 DCE error. Link has been cleared.
6–57
Table 6-11. Status Codes and Error Details for X.21 (Page 2 of 2)
Status
Code
Error
Detail
100
3
40
41
42
44
45
46
47
48
49
50
51
52
53
54
101
6–58
Definition
DCE error. Link has been cleared.
Parity error. DCE-provided information contains invalid parity.
DCE not ready.
Invalid DCE state. The DCE has signaled a state that is a protocol error.
CPS clear. ADCCP/X21 has cleared the connection due to a call progress signal.
Line overrun error. DCE-provided information was delivered too fast.
DCE protocol error. Received a string of DCE-provided information longer than
128 bytes without the character “+”.
DCE cleared the connection.
ADCCP/X21 has detected an internal error.
DTE time limit T1 expired.
DTE time limit T3A expired.
DTE time limit T3B expired.
DTE time limit TL expired.
Modem loss.
Invalid request for current line state.
Appendix A
File -System Error Codes
This appendix describes failure recovery strategies and lists the file-system error codes
pertaining to CP6100 or to the 3650/6100 family controllers. The error number, a brief
description of the error, what caused it, and a corrective action that you can take are
given for each error code.
Errors listed in table A-1 indicate that something was wrong with the request or the
device. The description briefly suggests what to do for each kind of error.
Errors listed Table A-2 indicate temporary resource shortages or path-switch
conditions. For temporary resource shortage, the request will probably work if you
repeat it.
Recovery Strategies
In your application, you will need to consider how to recover from path switches and
subsystem, LIU, or power failures. This subsection describes some possible strategies
for recovering from these types of failures.
Path Switches
Recovery from a path switch is more complex than recovery from device failures or
resource shortages. A path switch may leave the line state undefined. (In ADCCP, a
path switch does not change the state of the line. You can retry your request without
loss or duplication of data.) If your application retries writing to the line, it may be
sending text for the second time. If your application retries reading from the line, it
may not get the data you were expecting. For example, data arrives and is
acknowledged, but a failure occurs before the data is delivered to your application
buffer. In this case, repeating a read causes the remote station to send the next block
or message rather than the one that was lost because the remote station has already
received an acknowledgment for the lost data.
To handle a situation as described above, you can use end-to-end recovery. End-toend recovery is a strategy where you backtrack to the most recent point where you
knew what was happening. Here are three cases to illustrate the end-to-end-recovery
strategy:
Case 1
Your application was transmitting data when the error occurred. The normal
way to handle this is to repeat the last transmission, somehow signaling the
other station to discard any duplicate data. If a path switch changes the state
of the line in the protocol you are using, you may need to make another
request to restore the line state.
Case 2
Your application was receiving data when the error occurred. The normal
way to handle this is to abort the data transfer and start over, unless the
device understands an order to repeat its last transmission (or to repeat
transmission from a given point). If the application gets its data from
terminals, you will probably need to write a message on the appropriate
terminal, asking its user to type or submit the data again. If a path switch
changes the state of the line in the protocol you are using, you may need to
make another request to restore the line state.
A–1
Recovery Strategies
Case 3
You were establishing or severing a connection when the error occurred. The
best way to handle a mode-setting, line-bidding, or connection sequence is to
abort the sequence and start again from the beginning.
You may need to try your first WRITEREAD several times, until the line is in a state in
which the protocol can accept the request. For example, if the failure occurs while the
protocol is waiting to read, it may still be monitoring the line for data when you retry;
in that case, your application receives a message such as “wrong line state for this
operation,” and your application must keep trying until the earlier read operation
times out.
The request ID of a retry must match the request ID of the original request. The
request ID keeps the protocol from sending the same data twice or from delivering the
same data twice to the application.
The behavior of another station can also affect recovery. For instance, if the remote
station notes a delay and resets the line, its action causes a change in state, requiring
end-to-end recovery. CP6100 fault-tolerance cannot extend beyond the subsystem
cabinet.
Total Subsystem and LIU
Failures
An error condition sometimes affects more than one path to a device. CP6100 attempts
to recover from failures affecting more than one path to a device without adversely
affecting running applications.
If a path does not exist between the controllers and the 6100 subsystem cabinet (for
instance, if both cables are unplugged or the subsystem cabinet has no power), CP6100
queues user requests and completes them every 30 seconds with file system error 231.
When power returns, CP6100 downloads the line. Applications can resume using the
line, with the following restriction:
If the SYSGEN AUTOCLOSE parameter is set, applications must close and reopen
the line to use it again.
If the SYSGEN AUTOCONF parameter is set and applications have made
configuration changes, those changes must be restored (because the configuration
block has been overwritten).
The delay resulting from the failure may have caused a timeout or loss of the
communication link. It may be necessary to perform end-to-end recovery.
These same restrictions apply whenever the line is downloaded as the result of a CMI
START command or as part of an error recovery.
If an LIU does not respond to a request, CP6100 tries to establish contact through the
Communications Subsystem Manager (CSM) a maximum of three times. In the
meantime, requests finish with error 124. If the LIU fails to respond after three
attempts at recovery, CP6100 declares the line down and completes new requests with
error 66. (An operator must then use CMI to download the line and return it to
service.) If the LIU recovers, applications can resume using the line.
A–2
Recovery Strategies
If a status probe of the LIU reveals a malfunction, CP6100 attempts to recover
according to the error. For instance, if the probe reveals that power has returned,
implying an earlier failure, CP6100 downloads the LIU. If the SYSGEN AUTOLOAD
parameter is set, other problems that the status probe revealed will also cause a
download. Applications can resume their use of the line after the download, with the
same considerations mentioned in this subsection.
Power Failures
If a device seems unresponsive, the device may have had a power failure. The
following behaviors may indicate that a power failure has occurred:
An LIU that has lost power fails to respond to a status probe or to a frame sent by
CP6100. Application requests finish with error 124. If the LIU does not respond
after several attempts at recovery, CP6100 declares it down and requests finish
with error 66. When power returns, the operator must use CMI to start the line.
A controller that has lost power may cause timeouts on the I/O channel or a
failure by an LIU to respond to a status probe. This error may cause a path switch,
a download of the LIU, or both. If both controllers in a subsystem lose power,
requests finish every 30 seconds with error 231.
If a break-out board (BOB) (the device that connects a controller to a group of
LIUs) loses power, there are several possible symptoms. LIUs appear
unresponsive, as in the case of an LIU power failure, or a path switch occurs. as in
the case of a controller power failure.
A–3
File-System Error This subsection lists the file-system error codes and gives some hints for recovery.
Codes
Table A-1 lists error codes that are serious. If your application receives these codes, do
not retry the operation.
Table A-1. File-System Error Codes– Do Not Retry(Page 1 of 2)
Error
Code
2
12
14
21
22
53
A–4
Description/Solution
Invalid operation requested. You probably issued a call CP6100 doesn’t support.
Remember to use WRITEREADs for all requests to the line.
Device has been opened exclusively. The device is in use by another application. If other
applications use the line, or if your application opens the line more than once, make sure
you specify shared access in every OPEN call. If another application has the line open
exclusively, you must wait until that application closes the line.
Device does not exist. The line you named is not known to the system. Check your
spelling, and make sure the name is properly qualified, that is, that the system name is
correct.
Invalid count field in request. This message can mean one of the following:
The READ or WRITEREAD buffer is too small. It must be at least eight bytes long.
The write count parameter in the WRITEREAD call is not equal to the value in the Text
Out field plus 8.
The read count parameter in the WRITEREAD call is not equal to the value in the Text
In field plus 8.
The protocol task made an error in its response to CP6100 by delivering more or fewer
characters than it said it was delivering or by reporting a frame size that doesn’t match
the application request.
First check your program to see that your file system call was valid. If you suspect the
protocol task to be at fault, ask the system operator to stop the line and download the line
interface unit. If the problem persists, contact your Tandem representative.
Invalid request ID. The request ID in the WRITEREAD buffer is 0 or negative. Change it to
a number from 1 through 32767. (CP6100 does not check for duplicate request IDs. Your
application must manage its own request IDs in coordination with other applications using
the line.)
File-management interface error. Your application probably issued another request after
closing the line. Open the line again, and then repeat your request.
Table A-1. File-System Error Codes– Do Not Retry (Page 2 of 2)
Error
Code
24
60
61
66
99
100
201
1160
Nonresponding LIU; trying to reset. The LIU is not present in its slot, has not been powered
up, or is otherwise not working. (CP6100 issues a status probe every 10 seconds over the
primary path. This message means that there was no response to the most recent status
probe and that the CSM is trying to reset the LIU.) You may want to retry this request, in
case the reset succeeded. Otherwise, prepare the unit for operation—power it up and use
CMI to start it. This error can also indicate a loss of power to the BOB; prepare the BOB for
operation by restoring power to it.
Invalid open ID or not open. You made a request of a line or device without first opening it.
Either you forgot the OPEN call, a failure occurred during that call and you didn’t reissue it,
or the line was downloaded after being opened (with the SYSGEN AUTOCLOSE parameter
set). Open the line; if the line was downloaded after being opened, close it and open it
again.
Device suspended. The line or device is unable to accept OPEN requests. An operator
used CMI to suspend the device; have the operator activate the device, and then repeat the
operation.
Device down. The line or device cannot accept any requests; perhaps an operator used
CMI to stop the device, an error condition caused CP6100 to stop the device, or the line
interface unit has not been downloaded yet. This message can also mean that the protocol
rejected the configuration block. Check the console for messages about a possible
hardware failure. Ensure that there is power to the subsystem cabinet; then have the
operator use CMI to download and start the line interface unit; finally, repeat your request.
If the error persists, contact your Tandem representative.
No License for protocol software. There is probably something wrong with the software
license PROM. Contact your customer engineer.
Controller not operational. The controller is not present in its slot, is not addressed
correctly, has not been powered up, or has not been downloaded. Prepare the controller for
operation before you try the request again.
Error in message system interface. This message means CP6100 could not communicate
with the application. Possibly someone stopped both CPUs in which CP6100 was running;
repeat the request when CP6100 is running again. If the problem persists, call your
Tandem representative.
Request invalid for line state. Probably an operator used CMI to stop, suspend, or
otherwise change the state of the line during your request. If no one was using CMI, the LIU
malfunctioned. Check the console for messages regarding a hardware failure; have the
operator use CMI to make the line accessible again, and reissue your request.
A–5
Table A-2 lists error codes that your application can respond to by retrying the
operation.
Table A-2. File-System Error Codes– Retry
Error
Code
31
33
200
210
211
230
231
A–6
No buffer for #DEBUG. CP6100 couldn’t get a buffer to service a request for CSSDBUG.
This error is a specific case of error 33, below.
Buffer space shortage. CP6100 could not get a buffer for the request. Try the operation
again. If you get this error frequently, any of the following actions might help:
Move some lines to other processors, using SYSGEN or CMI, or add memory to the
processor to increase the amount of I/O segment space. CP6100 uses system I/O
segments for transfers to and from the line. That space is shared with all the I/O
processes running in the processor.
Add memory to the processor to increase available local pool space. (Local pool
space is set at 64K, but a shortage of physical memory may be preventing a full
allocation). CP6100 uses local pool space for transfers exceeding the size of a frame,
as defined in the line configuration. (A frame can never exceed 2K, but you might
define it to be smaller.) Local pool space is shared by all lines this CP6100 process
controls.
If you do not want to add memory to make more local pool available, use SYSGEN to
assign fewer lines to this CP6100 and use the MULTI parameter less than before.
Other ways to conserve local pool are to send smaller messages, to send fewer large
ones, or to change your frame size so fewer of your messages exceed it. Remember
that only large messages place demands on local pool.
Finally, consider the other applications that use the same lines (or lines in the same
processor). However you work to optimize your program, the message design of other
applications affects the buffer space available to you.
Device owned by other CPU. This message indicates that a path switch has occurred or is
occurring. See “Path Switches” in this appendix.
Path switch occurred. Device owned by other CPU. This message indicates that a path
switch has occurred or is occurring. See “Path Switches” in this appendix.
CPU failure. Device Owned by Other CPU. This message indicates that a path switch has
occurred or is occurring. See “Path Switches” in this appendix.
CPU power on. Device Owned by Other CPU. This message indicates that a path switch
has occurred or is occurring. See “Path Switches” in this appendix.
Controller power on, channel reset, or loss of contact with the 6100 subsystem cabinet. See
“Total Subsystem and LIU Failures” in this Appendix.
Appendix B
ADCCP Programming Example
Using TAL
This appendix contains an annotated sample of an application using ADCCP,
illustrating communication between two combined stations. The example includes
most of the requests described in Section 6, “Requests and Responses.” The
annotations include comments on the code as well as cross-references to parts of this
manual where specific topics are described. Annotations are in boldface type.
!MODIFIERS INDICATING THAT REQUEST FAILED OR WAS ABORTED
!
LTM^HOST^STOP = 24,
LTM^HOST^MODESET = LTM^HOST^STOP + 1,
LTM^LINE^MODESET = LTM^HOST^MODESET + 1,
LTM^MAX^RETRIES = LTM^HOST^MODESET + 1,
LTM^STATION^DISABLED = LTM^MAX^RETRIES + 1,
LTM^NO^RESPONSE = 40,
LTM^TEXTÔVERRUN = LTM^NO^RESPONSE + 1,
!
!MODIFIERS INDICATING A MODEM ERROR
!CAUSED REQ ABORT/LINE STATUS
!
LTM^DSR^LOSS = 32,
LTM^TXCLK^LOSS = LTM^DSR^LOSS + 1,
LTM^CARRIER^LOSS = LTM^TXCLK^LOSS + 1,
LTM^CTS^LOSS = LTM^CARRIER^LOSS + 1,
LTM^DSR^TIMEOUT = LTM^CTS^LOSS + 1,
!
!RECEIVETEXT RESPONSE STATUS BYTE VALUES INDICATING
!INPUT FRAME TYPE REC'D
!
LTMÎ^FRAME
= 00,
LTMÛI^FRAME
= 64,
LTM^RIM^SIM^CVD
= 65,
LTMÛSER0^RCD
= 66,
LTM^SARM^DM^CVD
= 67,
LTMÛP^RCVD
= 68,
LTM^SABM^RCV
= 71,
LTM^DISC^RD^CVD
= 72,
LTMÛSER1^RCD
= 74,
LTM^SARME^RCD
= 75,
LTMÛA^RCVD
= 76,
LTM^SABME^RCD
= 79,
LTM^SNRM^RCV
= 80,
LTM^FRMR^RSP^RCVD = 81,
LTMÛSER2^RCD
= 82,
LTM^RSET^RCV
= 83,
LTM^XID^RCVD
= 87,
LTMÛSER3^RCD
= 90,
LTM^SNRME^RCD
= 91,
LTM^TEST^RCV
= 92;
B–1
ADCCP Programming Example Using Transaction Application Language (TAL)
This example runs as a process pair. These definitions are used in the
implementation of fault tolerance.
int backupcrtpid[0:4],
!process id of backup
thiscpu,
backupcpu,
create^back := 0,
go^back := 0,
go^prime := 0;
int session;
!session is not checkpointed - on take over
!start a new session
int records^read,
records^written;
Every 30 seconds this program prints a message on the home terminal to indicate
how many data frames were sent and received.
!
!The following time variables are for determining
!when 30 seconds has passed
!
int start^time[0:2];
int(32) start = start^time[1];
int now^time[0:2];
int(32) now = now^time[1];
!
!From this point on, the global stack is
!checkpointed. NonStop:
!
int error := 0,
SERROR := 0,
exp^cnt,
!the tag for the read frame
first^time,
!flag to indicate first time reads
!are posted
do^sabm,
!TRUE = SABM
FALSE = DISCÔNLINE
!(wait for SABM)
startup^pri^sec^parm,
startup^says^sabm,
i,
INTTAG,
!INTEGER VERSION OF INT(32) VARIABLE TAG
count^trans,
savêrror,
io^count,
count^read,
fnumêrror,
total^length := 80,
base = error,
!base for checkpoints
suppress^length,
suppress^count,
recname [0:11] := ["$RECEIVE",8*[" "]],
framesize,
B–2
Definitions of files:
recfile: $RECEIVE
outfile: normally the home
terminalrfnum: used to read from the line
wfnum: used to write from the line
asynfnum: used to accept asynchronous responses
recfile,
outfile,
rfnum,
wfnum,
asynfnum, !file no. associated with async response
iosize,
lastâddr,
addresses,
write^dex,
out^key,
in^key,
buf^ptrs[0:6],
read^posted,
read^buf,
rbuf[0:256],
!buffer for asynchronous response
recbuff,
outbuf[0:80];
This is the template for a command or response buffer, including a Text field. The
fields are illustrated and described in in Section 6, "Requests and Responses.”
STRUCT SAMPLEMSG^FORMAT(*);
BEGIN
STRUCT MSG;
BEGIN
STRING
CMD;
STRING
MOD;
INT
REQÎD;
INT
TEXTÔUT;
INT
TEXTÎN;
STRUCT
TEXT;
BEGIN STRING BYTE[1:2048];
END;
END;
STRUCT COMMAND^RESPONSE = MSG;
BEGIN
STRING
RSP;
STRING
MOD;
INT
REQÎD;
INT
TEXTÔUT;
INT
TEXTÎN;
STRUCT
TEXT;
BEGIN
STRING BYTE[1:2048];
END;
INT TXT[1:1000] =TEXT; !REDEFINED TEXT INTO WORDS
END;
STRUCT BASIC = MSG;
BEGIN
STRING
CMD;
STRING
MOD;
INT
REQÎD;
INT
TEXTÔUT;
INT
TEXTÎN;
END;
B–3
This format is for a command or response buffer without a Text field.
STRUCT CONFIG = MSG;
BEGIN
STRING
CMD;
STRING
MOD;
INT
REQÎD;
INT
TEXTÔUT;
INT
TEXTÎN;
This format is for a command/response buffer for the SET CONFIGURATION or
FETCH CONFIGURATION request.
STRUCT TEXT;
BEGIN
INT MAX^FRAME^SIZE;
STRING MODE^SUPPORT,
ADDRESS^SIZE,
EXTENDED^CONTROL,
STATION^COUNT,
TRANSLATEÔN,
RNR^TIMER
TRANSLATEÔFFSET[1:2],
TRANSLATE^LENGTH[1:2],
POLL,
SREJOK,
REJOK,
RESERVD
TWS,
L2^WINDOW,
SWITCHED,
HALF^DUPLEX,
MODEM^LOSS^FATAL,
SWITCHEDÎNPUT^CARRIER,
SWITCHEDÔUTPUT^CARRIER,
FLAG^FILLÎDLE,
L2^RETRIES,
L1^RETRIES;
INT LINE^QUALITY;
INT TRANSFER^TIMER;
INT T1^TIMER;
INT IDLE^LINE^TIMER;
INT DSR^TIMER;
STRING ADDRESS^VALUE[1:4].
ABMSUPPÔFF,
ABMIPÔFF,
TESTFRAMES,
SUPPRESS^RR,
RESERVD,
OPTIONA,
OPTIONB;
END;
END;
END; !END OF TEMPLATE STRUCTURE
B–4
This structure is used as the command/response buffer in all requests that the
application makes to ADCCP. Note that this is the referral form:
SAMPLEMSG^FORMAT is the name of the template.
STRUCT .D(SAMPLEMSG^FORMAT);
!
!-- BELOW IS A STRUCTURE REPRESENTING THE FORMAT OF THE -- !
!
SET CONFIGURATION BLOCK OF PARAMETERS.
!
See the CONFIG structure, above.
STRUCT SET^CONFIG;
BEGIN
INT MAX^FRAME^SIZE;
STRING MODE^SUPPORT,
ADDRESS^SIZE,
EXTENDED^CONTROL,
STATION^COUNT,
TRANSLATEÔN,
RNR^TIMER
TRANSLATEÔFFSET[1:2],
TRANSLATE^LENGTH[1:2],
POLL,
SREJOK,
REJOK,
RESERVD
TWS,
L2^WINDOW,
SWITCHED,
HALF^DUPLEX,
MODEM^LOSS^FATAL,
SWITCHEDÎNPUT^CARRIER,
SWITCHEDÔUTPUT^CARRIER,
FLAG^FILLÎDLE,
L2^RETRIES,
L1^RETRIES;
INT LINE^QUALITY;
INT TRANSFER^TIMER;
INT T1^TIMER;
INT IDLE^LINE^TIMER;
INT DSR^TIMER;
STRING ADDRESS^VALUE[1:4],
ABMSUPPÔFF,
ABMIPÔFF,
TESTFRAMES,
SUPPRESS^RR,
RESERVD,
OPTIONA,
OPTIONB;
END; !END OF SET^CONFIG STRUCT
A move loads the request buffer (D) for a SET CONFIGURATION request or
unloads the response buffer for a FETCH CONFIGURATION request.
STRING B^SET^CONFIG = SET^CONFIG; !BYTE EQUIVALENCE FOR MOVES
!BETWEEN SET^CONFIG AND
!D.MSG.TEXT
B–5
Here, the default parameters defined as literals near the beginning of the listing are
grouped in an array.
STRING set^confârray = 'p' := [!l^max^frame^size,
!
!l^mode^support,
!
!lâddress^size
!
!lêxtended^control,
!
!l^station^count
!
!l^translateôn,
!
!l^rnr^timer
!
!l^translateôffset,
!
!l^translate^length,
!
!l^poll,
!
!l^srejok,
!
!l^rejok,
!
!l^reservd
!
!l^tws,
!
!l^l2^window,
!
!l^switched,
!
!l^half^duplex,
!
!l^modem^loss^fatal,
!
!l^switchedînput^carrier, !
!l^switchedôutput^carrier,!
!l^flag^fillîdle,
!
!l^l2^retries,
!
!l^l1^retries,
!
!l^line^quality, --- 500
!
!l^transfer^timer,
!
!l^t1^timer,
--- 500
!
!lîdle^line^timer,
!
!l^dsr^timer,
--- 300
!
!lâddress^value,
!
!lâbm^supportôff
!
!lâbmîpôff
!
!l^test^framesêcho........!
!lôption_two_off
!
1lôption^b
!
int(32) timeôut,
current^time,
!awaitio timeout value
!Current time in seconds relative
!from midnight
save^time,
!A save area for current^time
timeout^retry, !timeout * retry^count
tag,
RTAG;
!TAG FOR READ FRAMES
int itag = tag;
string
outbufs = outbuf,
ptr,
to^msg[0:to^msg^lnth],
suppress^buf[0:79] := ["Junk"],
sbuf := @outbuf '<<' 1,
rbufs := @rbuf '<<' 1;
struct .mesg;
begin
int type[0:1],
length,
data;
end;
!"CMD " or "RSP "
!words (includes itself)
struct .seed^msg (mesg);
define writeread^cnt = seed^msg.length '<<' 1 # ;
B–6
%001,%000,
1,
1,
0,
1,
0,
0,
0,0,
0,0,
255,
0,
255,
255,
0,
7,
0,
0,
0,
0,
0,
0,
3,
3,
%001,%364,
0,050,
%001,%364,
0,100,
%012,%360,
%301,0,0,0,0,
0,
0,
255
0,
0];
define write^posted = wbuf[0] #,
write^mcw
= wbuf[1] #,
write^data
= wbuf[2] #;
literal buf^head^size = 2;
Here is the structure of the startup message. When the program runs, infile will
contain the name of the ADCCP line; outfile will contain the name of the home
terminal or other output file.
struct .startup^msg;
begin
int msgcode,
volsubvol[0:7],
infile[0:11],
outfile[0:11];
string params[0:250];
end;
These strings are used to build the status messages printed on the terminal.
string
recêrror
async^resp
data^read
sage^reply
SAGE^REPLY1
=
=
=
=
=
'p'
'p'
'p'
'p'
'p'
:= ["RECEIVED", "### ### ",0],
:=["ASYNCHRONOUS RESPONSE:",0],
:= ["DATA READ BY",12*["'"],"%%%%%% %%%%%% %%%%%% %%%%%% %%%%%% %%%%%% %%%%%% %%%%%% ",0],
:= [12*["'"]," RSP
MOD
REQÎD TEXTOUT
TEXTIN
",0],
:= [12*["'"]," ###
###
######
############
",0];
literal fox^msg^size = 52; !words
This is the text that the program sends to the remote station. It is also the text that
the program expects to receive.
int brown^fox^msg = 'P' :=
["THE QUICK BROWN FOX JUMPED OVER THE LAZY MAN'S BACK.",
"the quick brown fox jumped over the lazy man's back."];
?NOLIST
?SOURCE $SYSTEM.SYSTEM.EXTDECS(ABEND,AWAITIO,CLOSE,CONTROL,DEBUG,DELAY,
?
FILEINFO,LOOKUPPROCESSNAME,NUMIN,NUMOUT,readupdate,reply,
?
GETCRTPID,MOM,MYPID,NEWPROCESS,TIME,MYSYSTEMNUMBER,
?
processorstatus,processinfo,lastaddr,checkopen,checkpoint,
?
monitorcpus,checkmonitor,lastreceive,deviceinfo,timestamp,
?
OPEN,READ,SETMODE,STEPMOM,STOP,WRITE,WRITEREAD)
?LIST
Procedure to timestamp the messages printed on the home terminal.
proc stamp^msg(s);
string .s;
begin
int .timeârray[0:6];
call time(timeârray);
call numout(s[0],timeârray[3],10,2);
s[2] := ":";
s[5] := ":";
s[8] := " ";
current^time := $dbl(timeârray[5] + timeârray[4] * 60) + $dbl(timeârray[3]) * 3600D;
!
seconds
minutes
hours
return;
end;
B–7
The next few procedures are part of the implementation of fault tolerance.
!Procedure to stop the backup process.
!
proc stop^backup;
begin
if backupcrtpid then call stop(backupcrtpid);
return;
end;
!
!Crashing - fire off a flare before doing so.
!
proc abend^;
begin
int p;
p := p[-3];
!pickup return address
call stamp^msg(sbuf);
sbuf[9] ':=' "___ ABEND at P = %" -> @ptr;
call numout(ptr,p,8,5);
call write(outfile,outbuf,@ptr '-' @outbuf'<<'1 '+' 5);
call awaitio(outfile);
backupcrtpid[3] := -1; !signal to stop the process pair
call stop^backup;
!this call will kill us, but if
!it does not then call abend;
!crash and burn
end;
?PAGE "NONSTOP HELPERS"
proc check(base);
int .base;
forward;
!
!Find Backup CPU Procedure
!
int proc select^backup(backup^cpu);
int .backup^cpu;
begin
int(32) cpuînfo;
int
prime^cpu,
found^cpu := false,
num^cpus = cpuînfo,
cpu^stat = cpuînfo+1;
cpuînfo := processorstatus;
backup^cpu := num^cpus;
prime^cpu := mypid.<0:7>;
while true do
if prime^cpu <> backup^cpu and ((%h8000 '>>' backup^cpu) land cpu^stat) then return true
else if (backup^cpu := backup^cpu - 1) < 0 then return false;
end;
?page "recvtext to flush reads and LTF^START on CHECKOPEN"
B–8
This procedure is used to flush reads at the beginning of a session and to issue the
START request after the backup process has opened the files. The procedure ends
with a a request to the ADCCP module. The calling routine furnishes the
WRITEREAD parameters as well as values to be placed in the request buffer (D).
proc RECFLUSH(filenumber,list,mod,txtout,txtin,cmd,count,tag^value) variable; !function
int filenumber,mod,txtout,txtin,count,cmd;
!value parameter
int(32) tag^value;
string .list;
begin
int length;
d.msg.cmd := cmd;
!MOVE FUNCTION BYTE
d.msg.mod := mod;
!MOVE MODIFIER
d.msg.reqîd
:= cmd;
!MOVE LENGTH OF TEXT FIELD IN!REQUEST
!MOVE LENGTH OF TEXT FIELD IN !RESPONSE
if NOT $PARAM(tag^value) then tag^value := 0D;
if $PARAM(list) then d.config.text ':=' list for txtout;
CALL WRITEREAD(filenumber,D,length,count,count^trans,tag^value);
end; !end of procedure
!
?PAGE "NonStop Procedures: PROC CREATEBACKUP"
!
!This procedure creates a backup process, checkopens its files, and
!checkpoints the stack from the global variable BASE to top-of-stack.
!
INT PROC CREATEBACKUP (BACKUPCPU,BACKUPCRTPID);
INT BACKUPCPU,
!input: backup cpu number
.BACKUPCRTPID;
!output:backup process id
BEGIN
int .program^file^name[0:11] := [12 * [" "]],
. process^name[0:3] := [4 * [0]],
error,
backêrror,
i;
string .string^ptr;
!
!subprocedure to start the backup process
!
int subproc go^backup;
begin
if error := processinfo(mypid,process^name,,,,program^file^name) then
begin
sbuf[9] ':=' " Error " -> @ptr;
call numout(ptr,error,10,3);
ptr[3] ':=' " returned from PROCESSINFO. Nonstop failure." -> @ptr;
return false;
end
else
begin
call newprocess(program^file^name,
0,
!priority
lastaddr'>>'10 + 1,
!memory pages
backupcpu,
!cpu #
backupcrtpid,
error,
process^name);
if <> then
begin
sbuf[9]':='" Error " -> @ptr;
ptr[5] ':=' " (%" -> @ptr;
call numout(ptr,error.<0:7>,8,5);
B–9
ptr[5] ':=' ",%" -> @ptr;
call numout(ptr,error.<8:15>,8,5);
ptr[5] ':=' ") returned from NEWPROCESS" -> @ptr;
return false;
end;
end;
return true;
end;
?page
!
!subprocedure for CHECKOPENing files.
!
int subproc go^checkô(filename,filenum,waitio,sync);
int .filename, .filenum, waitio, sync;
begin
if not sync then
call checkopen(filename,filenum,waitio,,,,backêrror)
else call checkopen(filename,filenum,waitio,sync,,,backêrror);
if backêrror <> 0 then
begin
sbuf[9] ':=' "BACKÊRROR " -> @ptr;
call numout(ptr,backêrror,10,3);
ptr[3] ':=' " returned from CHECKOPEN of file " -> @ptr;
@string^ptr := @filename '<<' 1;
sbuf[@ptr '-' @sbuf] ':=' string^ptr for 24 -> @ptr;
return false;
end;
return true;
end;
These lines result in a CHECKOPEN of every file opened by the primary process.
Like the primary process, the backup process opens the ADCCP line three times:
once for reading, once for writing, and once toreceive asynchronous messages.
!
!CREATEBACKUP main is here.
!
create^back := create^back + 1;
if go^backup then
if go^checkô(recname,recfile,1,1) then
if go^checkô(startup^msg.outfile,outfile,1,1) then
if go^checkô(startup^msg.infile,asynfnum,1,0) then
if go^checkô(startup^msg.infile,wfnum,7,0) then
if go^checkô(startup^msg.infile,rfnum,14,0) then
The SETMODE call allows I/O requests made by the backup to complete in any
order. The call to recflush results in a START request to ADCCP.
begin
call setmode(rfnum,30,1);
call recflush(rfnum,,0,0,0,ltf^start,$LEN(d.basic));
call awaitio(rfnum);
call check(base);
sbuf[9] ':=' "Backup process created in CPU " -> @ptr;
call numout(ptr,backupcpu,10,2);
call write(outfile,outbuf,@ptr[2] '-' @sbuf);
call check(base);
return true;
end;
call write(outfile,outbuf,@ptr '-' @sbuf);
call stop^backup;
return false;
END; !CREATEBACKUP
B–10
?PAGE "NonStop Procedures: PROC CHECK"
!
!This procedure is used to perform all checkpoints. It contains the
!logic to handle takeover situations.
!
PROC CHECK (BASE);
INT .BASE;
BEGIN
int status;
while (status:=checkpoint(base,,recfile,,outfile,,rfnum,,wfnum,,asynfnum)).<0:7>=2 do
begin
if createbackup(backupcpu,backupcrtpid) then
sbuf[28] ':=' ", Backup started." -> @ptr
else sbuf[28] ':=' ", Backup not started!!" -> @ptr;
sbuf[9] ':=' "Take Over by CPU ";
call numout(sbuf[26],mypid.<0:7>,10,2);
call readupdate(recfile,recbuff,recîo^size);
if <> then call abend^;
end;
return
END; !CHECK
!
?PAGE "NONSTOP^WHOAMI"
!NONSTOP^WHOAMI - Determine if backup or primary process.
!
proc nonstop^whoami;
begin
struct .ppd;
begin
int name[0:2],
pid1,
pid2,
ancestor[0:3];
end;
!
!Obtain the process-pair directory entry (ppd).
!
if not (error := processinfo(mypid,ppd)) then
begin
call lookupprocessname(ppd);
end
else call debug;
!
!Determine if backup or primary process. If backup, call checkmonitor.
!If primary, return to do what a primary does.
!
if ppd.pid2 <> 0 then !we are the backup.
begin
go^back := go^back + 1;
backupcpu := ppd.pid1.<0:7>;
call monitorcpus(%100000 '>>' ppd.pid1.<0:7>);
call checkmonitor;
call abend^;
!should not come here
end;
!
! We are the primary.
!
go^prime := go^prime + 1;
return;
end;
?page "SBLANK PROCEDURE"
proc sblank(str,bytes);
B–11
string .str; !string to be blanked
int bytes;
!number of blanks
begin
if bytes then
begin
str := " ";
str[1] ':=' str for bytes-1;
end;
end; !blank proc
?page "NEXTÊVENT"
This procedure completes RECEIVETEXT and SENDTEXT requests, asynchronous
reads, and system and process messages. The delay value is supplied by the user in
the startup message. (For instance, this program does not use tags on MODE SET
requests.)
!
!
NEXTÊVENT: - waits time "DELAY" for any IOs to complete;
! returns:
!
0 = read (RECEIVETEXT) complete
!
1 = write (SENDTEXT) complete
!
2 = timeout
!
3 = invalid tag or no tag on request
!
int proc nextêvent(delay);
int(32) delay;
begin
label wait^loop;
LITERAL STOP^MSG = -5,
!process stop message code
abend^msg = -6,
!process abend message code
node^change = -8,
!node cpu status change msg code
CPUÛP^MSG = -3;
!cpu reloaded message code
LITERAL NOTÂLLOWED = 2;
!operation not allowed on this device
INT LAST^PID[0:3],
!process id of requestor
MYNAME[0:3],
!my process id
fnum,
.
wbuf;
!
!Subproc to determine the type of $receive input.
!If the backup failed, it will be recreated.
!
int subproc system^msg;
begin
CALL LASTRECEIVE(LAST^PID);
!sender's PID
CALL PROCESSINFO(MYPID,MYNAME);
!my process name
IF LAST^PID <> [0,0,0] THEN
!not a system message
ELSE
!system message received
begin
IF (RECBUFF=STOP^MSG OR RECBUFF=abend^msg)! 1. backup process
AND (RECBUFF[1]=MYNAME FOR 3)
!
stopped or abended
OR RECBUFF = CPUÛP^MSG
! 2. backup cpu up
THEN CALL CREATEBACKUP(BACKUPCPU,BACKUPCRTPID);
end;
CALL REPLY (,,,,0);
!send reply: no error
B–12
CALL READUPDATE(RECFILE,RECBUFF,recîo^size);!post another readupdate
if <> then
begin
CALL FILEINFO(recfile,ERROR);
sbuf ':=' "$RECEIVE readupdate error: " -> @ptr;
call numout(sbuf[@ptr '-' @sbuf],error,10,5);
end;
if last^pid = [0,0,0] then return true;
!signal system msg
return false;
!signal process msg
end;
?page
!
!<<< main of nextêvent >>>
!
wait^loop:
fnum := -1;
call awaitio(fnum,,count^read,tag,delay);
call fileinfo(fnum,error);
if not fnum then !$receive input
if system^msg then goto wait^loop !loop on system msgs
else goto wait^loop;
! and on process msgs (unexpected)
if fnum = -1 and error = 40 then
return 2;
!timedôut
If the file number is rfnum, the request must be a RECEIVETEXT or a "control” type
request like MODE SET. This example uses rfnum only to make those kinds of
requests.
if fnum = rfnum then
begin
inttag := $int(tag);
!convert doubletag to integer
if inttag = 1 or inttag = 2 or inttag = 3 then
The request was a RECEIVETEXT.
begin
read^posted := false;
return 0;
end
The tag (inttag) was invalid, or the request was a "control" type request.
else return 3;
end;
If the file number is wfnum, the request must be a SENDTEXT request. This
example uses wfnum only for SENDTEXT requests.
if fnum = wfnum then
begin
!CONVERT DOUBLETAG TO INTEGER
INTTAG := $INT(TAG);
@wbuf := BUF^PTRS[INTTAG];
write^posted := false;
return 1;
!frameôut
end;
B–13
If the file number is asynfnum, an asynchronous read completed. The program
prints the asynchronous message on the home terminal.
if fnum = asynfnum and count^trans > 0 then
begin
sbuf ':=' "ASYNC RESPONSE:" -> @ptr;
call sblank(rbuf,30);
After an asynchronous read completes, the program issues another one to be sure
there is always a READ outstanding.
call read(asynfnum,rbuf,$LEN(d.command^response));
goto wait^loop;
end
!end of then loop
else call debug;
end;
This procedure opens the ADCCP line.
?PAGE "OPEN LINE PROCEDURE"
Proc open^line;
begin
int type,
reclnth;
These lines ensure that the infile in the startup message is actually a 6100 ADCCP
line.
call deviceinfo(startup^msg.infile,type,reclnth);
if type.<4:9> <> 51 or type.<10:15> <> 0 then
begin
sbuf ':=' ptr for 9 -> @ptr;
if not type then
ptr ':=' "is not defined." -> @ptr
else ptr ':=' "is not a 6100 ADCCP line." -> @ptr;
call abend^;
end;
sbuf ':=' "OPEN ERROR " -> @ptr;
call open(startup^msg.infile,rfnum,14); !read unit
The first OPEN, rfnum, will be used mainly for RECEIVETEXT requests.
if <> then
begin
call fileinfo(rfnum,error);
ptr[3] ':=' " on 1st open." -> @ptr;
call abend^;
end
else
begin
call setmode(rfnum,30,1);
end;
B–14
The second OPEN, asynfnum, will capture asynchronous messages.
call open(startup^msg.infile,asynfnum,1); !async response read
if <> then
begin
call fileinfo(asynfnum,error);
ptr[3] ':=' " on 1st open." -> @ptr;
call abend^;
end;
The third OPEN, wfnum, will be used for SENDTEXT requests.
call open(startup^msg.infile,wfnum,7); !write unit
if <> then
begin
call fileinfo(wfnum,error);
ptr[3] ':=' " on 1st open." -> @ptr;
call abend^;
end;
end;
This procedure (which is several pages long) opens $RECEIVE, reads and parses the
startup message, opens the home terminal or other output file, opens the line, starts
the backup process, and initializes the I/O buffers.
?page "STARTUP PROCEDURE"
PROC STARTUP;
BEGIN
int tô,
status := 0,
i,
.wbuf,
.temp[0:11];
string .ptr2,
. ptr3;
int(32) seconds,
minutes;
In the startup message, the user specifies PRI for primary or SEC for secondary.
Because the example uses ABM, it does not matter which value is supplied.
subproc check^startup^for^pri^sec^parms;
begin
int .ptr2;
@ptr := @startup^msg.params;
startup^pri^sec^parm := false;
while true do
begin
scan ptr while " " -> @ptr;
if $carry then return;
if ptr = "p" or ptr ="P" then
begin
!must be the PRI parm
startup^says^sabm := true;
startup^pri^sec^parm := true;
while ptr <> " " and ptr <> 0 do
begin
ptr := " ";
@ptr := @ptr[1];
end;
!blank out the parm
B–15
return;
end
else if ptr = "s" or ptr ="S" then
begin
!must be the SEC parm
startup^says^sabm := false;
startup^pri^sec^parm := true;
while ptr <> " " and ptr <> 0 do
begin
ptr := " ";
@ptr := @ptr[1];
end;
return;
end
else
begin
scan ptr until " " -> @ptr;
if $carry then return;
end;
end;
!blank out the parm
end;
These lines get the addresses of the primary and secondary substations from the
startup message. The address of the local primary substation is later used in the
DEFINELIST request. The address of the local secondary substation is used in the
!
!The address parameter is in the startup message in the form:
!ADDRESS(x,y) or ADDR(x,y) or A(x,y)
!After the address parameter has been found, it is blanked from
!the startup message to make further parameter parsing easier.
!
int subproc getâddrs;
begin
int a1,a2;
scan startup^msg.params until "a" -> @ptr;
if $carry then scan startup^msg.params until "A" -> @ptr;
if $carry then return false;
scan ptr until "(" -> @ptr2;
scan ptr2[1] while " " -> @ptr2;
call numin(ptr2,a1,10,status);
if status then return false;
scan ptr2[1] until "," -> @ptr2;
scan ptr2[1] while " " -> @ptr2;
call numin(ptr2,a2,10,status);
if status then return false;
scan ptr until ")" -> @ptr2;
ptr ':=' " " & ptr for @ptr2 '-' @ptr;
Local primary substation.
addresses.<0:7> := a1;
Local secondary substation.
addresses.<8:15> := a2;
return true;
end;
B–16
!
!
!<<< BEGIN STARTUP >>>
!
call nonstop^whoami;
!no return if backup
Is this the primary process? If so, open $RECEIVE and read the startup message.
CALL OPEN(recname,recfile,1,1);
IF <> THEN CALL ABEND^;
CALL READ(recfile,startup^msg,$len(startup^msg));
CALL AWAITIO(recfile,,count^read);
startup^msg.params[count^read-41] := 0;
Open the home terminal (or other output file).
call open(startup^msg.outfile,outfile,1,1);
!
!The infile is the ADCCP line name.
!
call open^line;
Open the ADCCP line.
!
!Obtain the line addresses value from startup message.
!
Get the addresses.
if not getâddrs then
begin
sbuf ':=' "Missing or invalid ADDRESS(x,y) parameter." -> @ptr;
call abend^;
end;
call check^startup^for^pri^sec^parms;
Find out the station type (doesn't matter for ABM).
!
!Obtain the framesize (words) value from startup message.
!
status := 0;
!preset status no error
Get the frame size.
framesize := 128;
!preset default to 128 words
scan startup^msg.params while " " -> @ptr;
if not $carry then call numin(ptr,framesize,10,status);
if status then
begin
i := @ptr;
!save ptr
sbuf ':=' "Illegal FRAMESIZE value. NUMIN STATUS = " -> @ptr;
call numout(ptr,status,10,4);
framesize := 128; !use default
ptr[4] ':=' ". Using default of 128 words." -> @ptr;
@ptr := i;
!restore ptr
end;
B–17
Get the timeout value for I/O requests to the ADCCP line. If the user supplied an
illegal value, use 4 seconds by default.
!
!Obtain the timeout value from startup message.
!
status := 0;
!preset status no error
tô := 400;
!preset default to 4 seconds
scan ptr until " " -> @ptr;
scan ptr while " " -> @ptr;
if not $carry then call numin(ptr,tô,10,status);
if status then
begin
sbuf ':=' "Illegal TIMEOUT value. NUMIN STATUS = " -> @ptr;
call numout(ptr,status,10,4);
tô := 400;
!use default
ptr[4] ':=' ". Using default of 4 seconds." -> @ptr;
end;
timeôut :=$dbl(tô);
!
!
!
!
Now tell the user:
1. Line Name.
2. FRAMESIZE
3. Timeout
Report the line name.
sbuf[9] ':=' "The 6100 ADCCP line is " & ptr for 8 -> @ptr;
Report the frame size.
sbuf[9] ':=' "The FRAMESIZE is " -> @ptr;
call numout(ptr,framesize,10,3);
ptr[3] ':=' " words." -> @ptr;
!
!Build TIMEÔUT message.
!
seconds := timeôut/100D;
if (timeôut - (seconds * 100D) > 49D) then seconds := seconds + 1D;
minutes := seconds / 60D;
seconds := seconds - (minutes * 60D);
to^msg ':=' " " & to^msg for to^msg^lnth;
if seconds = 0D and minutes = 0D then
to^msg[3] ':=' "0 to .49 second timeout." -> @ptr
else if minutes <> 0D then
begin
tô := $int(minutes);
call numout(to^msg[3],tô,10,2);
to^msg[5] ':=' " minute " -> @ptr;
end
else @ptr := @to^msg[3];
if seconds <> 0D then
begin
tô := $int(seconds);
call numout(ptr,tô,10,2);
B–18
4. Addresses
ptr[2] ':=' " second " -> @ptr;
end;
ptr ':=' "AWAITIO time out";
scan to^msg while " " -> @ptr;
i := to^msg^lnth '-' (@ptr '-' @to^msg);
to^msg ':=' ptr for i;
to^msg[i] ':=' " " & to^msg[i] for to^msg^lnth - i - 1;
!
sbuf[9] ':=' to^msg for to^msg^lnth -> @ptr;
Report the timeout interval.
!
!Tell user what addresses we are using;
!
sbuf[9] ':=' "Using addresses: " -> @ptr;
call numout(ptr,addresses.<0:7>,10,3);
ptr[3] ':=' "," -> @ptr;
call numout(ptr,addresses.<8:15>,10,3);
Report the addresses.
!
!
!
select a backup cpu and startup a backup process.
if select^backup(backupcpu) then ! ok, backup selected
else call abend^;
call monitorcpus(%100000 '>>' backupcpu);
Start the backup process.
@recbuff := lastaddr '-' recîo^size;
lastâddr := @recbuff;
call readupdate(recfile,recbuff,recîo^size);
if not createbackup(backupcpu,backupcrtpid) then call abend^;
!
!Init storage for I/O buffers;
!Lastaddr is now @recbuff - 1;
!
@read^buf := lastâddr - framesize - 1;
lastâddr := @read^buf;
Initialize buffers. The station sends 6 frames at a time.
for i := 0 to 5 do !loop and allocate the write buffers
begin
buf^ptrs[i] := lastâddr - framesize - buf^head^size;
@wbuf := lastâddr := buf^ptrs[i];
end;
!
!OK - all set.
!
sbuf[9] ':=' "=" & sbuf[9] for 41 -> @ptr;
END;
B–19
?page
!
proc put^suppress^msg;
begin
string .ptr2;
call stamp^msg(sbuf); !place a time stamp in sbuf[0:8]
sbuf[9] ':=' "Suppressed " -> @ptr2;
call numout(sbuf[@ptr2 '-' @sbuf],suppress^count,10,5);
ptr2[5] ':=' ": " -> @ptr2;
ptr2 ':=' suppress^buf for suppress^length -> @ptr2;
call write(outfile,outbuf,@ptr2 '-' @sbuf);
suppress^count := 0;
suppress^buf ':=' " " & suppress^buf for suppress^length - 1;
return;
end;
?page
!
!On entry: sbuf contains the message
!ptr -> next free byte of message
!error <> 0 means to NUMOUT the error at ptr.
!
This procedure writes error messages, asynchronous responses, etc., on the terminal.
proc writeêrr^msg;
begin
int
i;
string .temp^buf[0:80];
if error then
!Note: ERROR is preset by the caller
begin
call numout(sbuf[@ptr '-' @sbuf],error,10,4);
@ptr := @ptr[4];
end;
i := @ptr '-' @sbuf[9];
!length of message (excluding the timestamp portion)
!place time stamp in message, also sets current^time
if suppress^count then
if suppress^buf '=' sbuf[9] for i then
begin !suppress another error msg
if (suppress^count := suppress^count + 1) = 32767
or (current^time-save^time) > 180D !seconds! then
call put^suppress^msg;
return;
end
else !a different error
begin
temp^buf ':=' sbuf[9] for i;
call put^suppress^msg;
sbuf[9] ':=' temp^buf for i;
end
else if suppress^buf '=' sbuf[9] for i then
begin
suppress^count := 1;
save^time := current^time;
return;
end;
save^time := current^time;
suppress^buf ':=' sbuf[9] for i;
suppress^length := i;
call write(outfile,outbuf,i + 9);
return;
end;
B–20
?PAGE "I/O FORMATTING"
This procedure completes the requests associated with starting up the link:
FETCH CONFIGURATION
SET CONFIGURATION
DEFINELIST
START
MODE SET
int proc checkâwaitio(time,CMD) variable; !function procedure
INT CMD;
!VALUE PARAMETER
int(32) time;
!value parameter
begin
int any^file ;
restart:
any^file := -1;
tag := "junk";
call awaitio(any^file,,count^trans,tag,time);
call fileinfo(any^file,error);
IF NOT $PARAM(CMD) THEN CMD := 0;
Serror := CMD;
Timeout.
if error = 40 then goto restart;
Asynchronous response received.
if any^file = asynfnum and count^trans > 0
then begin
error := 500;
sbuf[9] ':=' "ASYNC RESP" -> @ptr;
Call procedure to print error message on terminal. In this case, the message
consists of a timestamp, the words "ASYNC RESP," and the error number (500).
!
call writeêrr^msg;
error := 0;
Immediately post another READ to replace the one that completed.
goto restart;
end;
!end of then loop
These lines check for the successful completion of the specified request (CMD,
passed by the caller). If an error occurred or the wrong request completed, the
procedure notifies the caller.
IF NOT ERROR THEN
BEGIN
IF NOT (D.COMMAND^RESPONSE.RSP = CMD AND
D.COMMAND^RESPONSE.MOD = LTMÔK AND
D.COMMAND^RESPONSE.REQÎD = CMD)
THEN BEGIN
ERROR := 300;
ERROR.<8:15> := ERROR.<8:15> + D.COMMAND^RESPONSE.MOD;
END;
END;
B–21
return error;
end;
!end of checkâwaitio procedure
This procedure issues all requests to the ADCCP protocol module , except those
requests handled by the recflush procedure above.
proc receive(filenumber,list,txtout,txtin,cmd,count,tag^value) variable; !functio
int filenumber,txtout,txtin,count,cmd;
!value parameters
int(32) tag^value;
string .list;
begin
int length;
d.msg.cmd := cmd;
!MOVE FUNCTION BYTE
d.msg.mod := 0;
!MOVE MODIFIER
d.msg.reqîd
:= cmd;
!MOVE LENGTH OF TEXT FIELD IN !RESPONSE
if NOT $PARAM(tag^value)
then tag^value := 0D;
if $PARAM(list) then
d.config.text ':=' list for txtout;
This is a request to the ADCCP protocol module. The calling procedure furnishes
the WRITEREAD parameters, as well as values to be placed in the request buffer
(D).
end;
!end of procedure
This procedure makes the requests needed to start up the line.
?page "SETMODE^LINE"
Int proc setmode^line;
begin
INT P1,P2;
INT(32) WAIT^TIME;
WAIT^TIME := 1000D;
!10 SECONDS
FETCH CONFIGURATION request.
call receive(rfnum,,0,40,ltf^fetch^config,$LEN(d.basic)+40);
CALL CHECKÂWAITIO(WAIT^TIME,LTF^FETCH^CONFIG);
IF ERROR THEN
BEGIN
sbuf[9] ':=' "fetch config error: " -> @ptr;
call writeêrr^msg;
RETURN FALSE;
END;
!MOVE THE DEFAULT PARAMETERS FROM D.MSG.TEXT
B^SET^CONFIG ':=' D.CONFIG.TEXT
FOR $LEN(SET^CONFIG);
if startup^pri^sec^parm then
!STARTUP msg will override SYSGEN
if startup^says^sabm then
do^sabm := true
else do^sabm := false;
These assignments override various defaults in the configuration block.
!SET ABM MODE AND NO TRANSLATION
SET^CONFIG.MODE^SUPPORT := ABM;
SET^CONFIG.TRANSLATEÔN := FALSE;
! ENSURE FDX ,TWS MODE OF OPERATION
IF SET^CONFIG.MODE^SUPPORT = NRM OR SET^CONFIG.MODE^SUPPORT = ARM
THEN SET^CONFIG.REJOK := TRUE;
SET^CONFIG.TWS := TRUE;
SET^CONFIG.HALF^DUPLEX := FALSE;
SET^CONFIG.MAX^FRAME^SIZE := (FRAMESIZE + FRAMESIZE);
B–22
Address of a local secondary substation.
SET^CONFIG.ADDRESS^VALUE[1] := ADDRESSES.<8:15>; !LOCAL SEC./REMOTE PRIM.
SET^CONFIG.ADDRESS^SIZE := 1;
!SET ADDRESS OCTET TO 1
P1 := SET^CONFIG.T1^TIMER;
P2 := SET^CONFIG.L2^RETRIES;
CALL RECEIVE(RFNUM,B^SET^CONFIG,40,0,LTF^SET^CONFIG,$LEN(D.BASIC));
WAIT^TIME := 1000D;
!10 SECONDS
CALL CHECKÂWAITIO(WAIT^TIME,LTF^SET^CONFIG);
IF ERROR THEN
BEGIN
sbuf[9] ':=' "set config error: " -> @ptr;
call writeêrr^msg;
RETURN FALSE;
END;
!SET DEFINELIST TEXT PARAMETERS --- ASSUME ABM MODE OF OPERATION
D.MSG.TEXT.BYTE[1] := 1;
D.MSG.TEXT.BYTE[2] := COMBINED;
Address of local primary substation, from startup message.
D.MSG.TEXT.BYTE[4] := ADDRESSES.<0:7>;
CALL RECEIVE(RFNUM,,4,0,LTF^DEFINELIST,$LEN(D.BASIC));
WAIT^TIME := 1000D;
!10 SECONDS
DEFINELIST request.
CALL CHECKÂWAITIO(WAIT^TIME,LTF^DEFINELIST);
IF ERROR THEN
BEGIN
sbuf[9] ':=' "definelist error: " -> @ptr;
call writeêrr^msg;
RETURN FALSE;
END;
START request.
CALL RECEIVE(RFNUM,,0,0,LTF^START,$LEN(D.BASIC));
WAIT^TIME := 10D;
!10 SECONDS
CALL CHECKÂWAITIO(WAIT^TIME,LTF^START);
IF ERROR THEN
BEGIN
sbuf[9] ':=' "ltf^start error: " -> @ptr;
call writeêrr^msg;
RETURN FALSE;
END;
timeout^retry := $dbl(p1) * $dbl(p2); !save total time to timeout
call delay(250D);
!delay ot get the line ready
return true;
!signal success
end;
B–23
?PAGE "MAIN PROCEDURE"
PROC main^ MAIN;
BEGIN
subproc some^moreînit;
begin
int .wbuf;
write^dex := out^key := in^key := 0;
for i := 0 to 5 do
!loop and flag all write buffers available
begin
@wbuf := buf^ptrs[i];
end;
end;
This procedure cancels any dangling I/O requests.
subproc cancelîo^pipes;
begin
restart: call
awaitio(asynfnum,,COUNT^TRANS,tag,1D);
Check for an asynchronous read and print a message on the terminal, if needed.
call fileinfo(asynfnum,error);
if COUNT^TRANS > 0
then begin
error := 500;
sbuf[9] ':=' "ASYNC RESPONSE:
call writeêrr^msg;
error := 0;
" -> @ptr;
Issue another READ request, so one is always pending.
goto restart;
end;
!end of then loop
B–24
Complete an outstanding RECEIVETEXT request. Continue the loop until there are
no more RECEIVETEXT requests outstanding.
do
begin
call awaitio(rfnum,,,tag,1D);
call fileinfo(rfnum,error);
inttag := $int(tag);
if not error and (inttag=1 or inttag= 2 or inttag=3)
Report the results. Note that the way to "cancel" a request is to complete it and
ignore the data.
then begin
sbuf[9] ':=' "CANCELÎO^PIPES sucked up a read." -> @ptr;
call writeêrr^msg;
end
else if error then
if error = 40 or error = 26 then !OK
else
begin
sbuf[9] ':=' "CANCELÎO^PIPES READ error: " -> @ptr;
call writeêrr^msg;
end ;
end
until error = 26;
Complete an outstanding SENDTEXT request. Continue the loop until there are no
more SENDTEXT requests outstanding.
do
begin
call awaitio(wfnum,,,tag,1D);
call fileinfo(wfnum,error);
if error then
if error = 40 or error = 26 then !OK
else
Report an error, if necessary.
begin
sbuf[9] ':=' "CANCELÎO^PIPES WRITE error:
call writeêrr^msg;
end ;
end
until error = 26;
call some^moreînit;
" -> @ptr;
!re-init write buffers
end;
This procedure starts a session by identifying the station as active and issuing a
SABM.
int subproc start^session;
begin
int(32) wait^time;
call cancelîo^pipes;
!be safe - cancel any dangling ios
!station id
D.MSG.TEXT.BYTE[2] := active;
!reset ERRORSTOP bit
call receive(RFNUM,,2,0,ltf^changelist,$LEN(d.basic));
wait^time := 1000D;
!wait 10 seconds
B–25
CHANGELIST request.
call checkâwaitio(wait^time,ltf^changelist);
if error then
begin
sbuf[9] ':=' "changelist error : " -> @ptr;
call writeêrr^msg;
return false;
end;
d.msg.text.byte[1] := 1;
d.msg.text.byte[2] := M^SABM;
!set ABM mode
MODE SET request.
call receive(rfnum,,2,2,ltf^mode^set,$LEN(d.basic)); !SABM
wait^time := 1000D;
!wait 10 seconds
call checkâwaitio(wait^time,ltf^mode^set);
if error then
begin
sbuf[9] ':=' "modeset error: " -> @ptr;
call writeêrr^msg;
return false;
end;
first^time := true;
!session started -- post 3 reads flag
RETURN TRUE;
!SESSION STARTED FOR BOTH SIDES
end;
This procedure builds the Text field for a SENDTEXT request.
subproc build^buf(wbuf);
int .wbuf;
begin
int length^left,
.iptr;
length^left := framesize - 1;
These are the contents of the first word of the text field.
write^mcw.<0:7> := 1;
Write^mcw.<8:15> := 0;
@iptr := @write^data;
!station id
!DO NOT SET P/F BIT FOR Station status
The second word of the text field is out^key, which serves as a sequence number
for the frame. Out^key is specific to this application; ADCCP regards it simply as
data. The field "The quick brown fox..." occurs as often as the frame size allows,
with an instance of out^key preceding each instance of "The quick brown fox...."
Out^key increases by 1 for each frame and wraps around after 32767.
while length^left do
begin
iptr := out^key;
if (length^left := length^left - 1) then
if length^left >= fox^msg^size then
begin
iptr[1] ':=' brown^fox^msg for fox^msg^size -> @iptr;
length^left := length^left - fox^msg^size;
end
else
begin
iptr[1] ':=' iptr for length^left;
length^left := 0;
end;
end;
B–26
if (out^key := out^key + 1) = 32767 then out^key := 0;
end;
This procedure posts RECEIVETEXT and SENDTEXT requests.
subproc postîos;
begin
int .wbuf,i,loop^cnt;
if not read^posted then
begin
if first^time
If these are the first I/O requests to be posted after the link is established, the
program posts 3 RECEIVETEXT requests. The first request has a tag of 1, the
second has a tag of 2, and the third has a tag of 3.
THEN BEGIN
loop^cnt := 3;
BEGIN
for i := 1 to loop^cnt do
begin
RTAG := $DBL(i);
call sblank(d,iosize+$LEN(d.basic));
The first request is a special form, with a modifier of 255; it flushes ADCCP's read
queues. Note that in a RECEIVETEXT request, the Text In value is 0. ADCCP
ignores it and accepts as much data as the frame size will allow.
if i = 1 then
call recflush(rfnum,,255,0,0,ltf^rcvtext,iosize+$LEN(d.basic),RTAG)
else
call receive(rfnum,,0,0,ltf^rcvtext,iosize+$LEN(d.basic),RTAG);
end;
END;
!END OF DO LOOP
END
!END OF FIRST^TIME BEING TRUE
If this is not the beginning of the session, the program posts one RECEIVETEXT
request.
else begin
IF EXP^CNT = 1 THEN RTAG := $DBL(3)
ELSE RTAG :=$DBL(exp^cnt -1);
call sblank(d,iosize+$LEN(d.basic));
call receive(rfnum,,0,0,ltf^rcvtext,iosize+$LEN(d.basic),RTAG);
end;
The next RECEIVETEXT request to complete should have a tag equal to exp^cnt.
(See subproc frameîn, below.)
if first^time then exp^cnt := 1;
first^time := false;
read^posted := true;
end;
@wbuf := buf^ptrs[write^dex];
If there is no SENDTEXT posted, the program posts a SENDTEXT. The tag is a
number from 0 to 5; the first frame sent has a tag of 0, the second has a tag of 1, and
so on. The value of the tag wraps around after 5.
while not write^posted do
begin
call build^buf(wbuf);
itag[0] := 0;
B–27
itag[1] := write^dex;
d.command^response.txt[1] ':=' write^mcw for iosize/2 ;
call receive(wfnum,,iosize,0,ltf^sendtext,$LEN(d.basic),tag);
write^posted := true;
if write^dex = 5 then
write^dex := 0
else write^dex := write^dex + 1;
@wbuf := buf^ptrs[write^dex];
end;
end;
!
The main procedure calls frameîn after a RECEIVETEXT completes.
subproc frameîn;
begin
int length^left,IPTR;
The tag is compared to the expected value. Then, exp^cnt is increased by 1 to match
the next expected tag. If the tag does not match the expected value, the program
reports an error and discontinues the session.
if inttag = exp^cnt then
begin
if exp^cnt = 3 then exp^cnt := 1
else exp^cnt := exp^cnt + 1;
end
else
begin
sbuf[9]':='"??? READ TAG invalid"->@ptr;
call writeêrr^msg;
session := false;
return;
end;
If no file-system error occurred, the program ensures that the function was
RECEIVETEXT and that it completed successfully. A 0 in the second byte of the
buffer means that the P/F bit was off; a 128 means that it was on (but both are
successful completions). If a file-system error occurred or if the buffer contained an
error code, the program reports an error to the user and discontinues the session.
if not error then
IF NOT (D.COMMAND^RESPONSE.RSP = ltf^RCVTEXT and
D.COMMAND^RESPONSE.MOD = LTMÔK OR
D.COMMAND^RESPONSE.MOD = 128 AND
D.COMMAND^RESPONSE.REQÎD = ltf^RCVTEXT)
then BEGIN
ERROR := 300;
END;
IF ERROR THEN
BEGIN
sbuf[9] ':=' "READ ERROR: " -> @ptr;
call writeêrr^msg;
session := false;
return;
end;
B–28
If the frame that arrived was a SABM (an I-frame would have a Text In value
greater than 2), the program immediately posts a RECEIVETEXT with the same tag
as in the request that completed. (The decrement here undoes the increment that
occurred earlier in the procedure.)
IF D.COMMAND^RESPONSE.TEXTÎN = 2 THEN
!SABM FRAME
BEGIN
READ^POSTED := FALSE;
!POST ANOTHER READ
IF EXP^CNT = 1 THEN RTAG := $DBL(3)
ELSE RTAG := $DBL(exp^cnt -1);
CALL SBLANK(D,IOSIZE+$LEN(D.BASIC));
CALL RECEIVE(RFNUM,,0,0,LTF^RCVTEXT,IOSIZE+$LEN(D.BASIC),RTAG);
READ^POSTED := TRUE;
RETURN;
END;
length^left := framesize - 1;
IPTR := 1;
!first word of text is station-id,station-status
The second word of the text field is in^key, which serves as a sequence number for
the frame. See the out^key in the build^buf subprocedure.
while length^left do
begin
if in^key <> D.COMMAND^RESPONSE.TXT[IPTR+1] then goto frameînêrr;
if (length^left := length^left - 1) then
if length^left >= fox^msg^size then
begin
if D.COMMAND^RESPONSE.TXT[IPTR+2] '<>' brown^fox^msg for fox^msg^size then
goto frameînêrr;
length^left := length^left - fox^msg^size;
IPTR := IPTR + 1 + FOX^MSG^SIZE;
end
else
If the text received is accurate, the program increases the sequence number and the
count of frames read by 1.
If D.COMMAND^RESPONSE.TXT[IPTR+2] '<>' D.COMMAND^RESPONSE.TXT[IPTR+1]
for length^left then
goto frameînêrr
else length^left := 0
else;
end;
if in^key = 32767 then
in^key := 0
else in^key := in^key + 1;
records^read := records^read + 1;
return;
frameînêrr:
sbuf[9] ':=' "Lost message or bad data @ in^key = " -> @ptr;
call numout(ptr,in^key,10,5);
@ptr := @ptr[5];
call writeêrr^msg;
session := false;
!this will kill us
end;
B–29
The main procedure calls frameôut after a SENDTEXT request completes. If no
file system error occurred but the buffer containsan error code, the program checks
for a mode-setting frame received from the other station.
subproc frameôut;
begin
INT
.WBUF,LENGTH^FRAME,WPTR;
if not error then
begin
IF NOT (D.COMMAND^RESPONSE.RSP = ltf^sendtext and
D.COMMAND^RESPONSE.MOD = LTMÔK and
D.COMMAND^RESPONSE.REQÎD = ltf^sendtext)
then BEGIN
IF D.COMMAND^RESPONSE.RSP = LTF^SENDTEXT AND
D.COMMAND^RESPONSE.MOD = LTM^HOST^MODESET AND
D.COMMAND^RESPONSE.REQÎD = LTF^SENDTEXT
THEN GOTO FRAMEÔUTÊRR
If a file-system error occurred or if the error code was not a mode-set condition, the
program reports the problem to the user and discontinues the session.
ELSE BEGIN
ERROR := 300;
END;
END;
end;
IF ERROR THEN
BEGIN
sbuf[9] ':=' "WRITE ERROR: " -> @ptr;
call writeêrr^msg;
session := false;
return;
END
If the SENDTEXT request completed without error, the count of frames written
increases by 1.
else begin
records^written := records^written + 1;
return;
end;
FRAMEÔUTÊRR:
@WBUF := BUF^PTRS[INTTAG];
LENGTH^FRAME := FRAMESIZE -1;
WPTR := 1;
D.COMMAND^RESPONSE.TXT[1].<0:7> := 1;
D.COMMAND^RESPONSE.TXT[1].<8:15> := 0;
D.COMMAND^RESPONSE.TXT[2] := out^KEY;
!STATION ID
!STATION STATUS
If the SENDTEXT request completed with a mode-setting frame, the program issues
another SENDTEXT with the same tag as before.
IF (LENGTH^FRAME := LENGTH^FRAME -1 ) THEN
IF LENGTH^FRAME >= FOX^MSG^SIZE THEN
BEGIN
D.COMMAND^RESPONSE.TXT[WPTR+2] ':=' BROWN^FOX^MSG FOR FOX^MSG^SIZE;
LENGTH^FRAME := LENGTH^FRAME - FOX^MSG^SIZE;
WPTR := WPTR + 1 + FOX^MSG^SIZE;
END
ELSE
D.COMMAND^RESPONSE.TXT[WPTR+2] ':=' D.COMMAND^RESPONSE.TXT[WPTR+1] FOR LENGTH^FRAME;
CALL RECEIVE(WFNUM,,IOSIZE,0,LTF^SENDTEXT,$LEN(D.BASIC),TAG);
WRITE^POSTED := TRUE;
IF out^KEY := 32767 THEN
B–30
end;
out^KEY := 0
ELSE out^KEY := out^KEY + 1;
!END OF SUBPROCEDURE
This subprocedure prints a pair of messages every 30 seconds to tell how many
frames have been sent and received.
subproc timedôut;
begin
sbuf[9] ':=' "Timeout." -> @ptr;
call writeêrr^msg;
end;
?page
subproc seeîf^30^seconds^has^passed;
begin
int
max^time[0:1] := [%77777,-1];
int(32) max = max^time,
time^passed;
call timestamp(now^time);
start^time[1].<0> := 0;
!turn off sign bit of "start"
now^time[1].<0> := 0;
!turn off sign bit of "now"
if (time^passed := now - start) < 0D then
time^passed := max + time^passed;
if time^passed >= 3000D then
begin
!30 seconds has passed
if suppress^count then call put^suppress^msg;
call numout(sbuf[9],records^read,10,5);
sbuf[14] ':=' " records of " -> @ptr;
call numout(ptr,(framesize - 1) '<<' 1,10,4);
ptr[4] ':=' " bytes each were read." -> @ptr;
call writeêrr^msg;
call numout(sbuf[9],records^written,10,5);
sbuf[14] ':=' " records of " -> @ptr;
call numout(ptr,(framesize - 1) '<<' 1,10,4);
ptr[4] ':=' " bytes each were written." -> @ptr;
call writeêrr^msg;
start^time ':=' now^time for 3;
records^read := records^written := 0;
end;
end;
?page "MAIN of MAIN"
!
!
<<< MAIN >>>
!
Open files and initialize buffers.
call startup;
call setmode(asynfnum,30,1);
Prepare to receive asynchronous messages.
CALL READ(ASYNFNUM,RBUF,$LEN(D.BASIC));
if < then call fileinfo(asynfnum,error);
call check(base);
Set the configuration and start the line.
if not setmode^line then call abend^;
session := false;
iosize := framesize '<<' 1; !bytes
!crash if unable to SETMODE the line
!line is ready but no session yet.
B–31
Establish the session.
!
! Loop Forever
!
while true do
begin
call check(base);
while not start^session do; !loop until session started
session := true;
sbuf[9] ':=' "============ SESSION STARTED =============" -> @ptr;
sbuf[9] ':=' "==========================================" -> @ptr;
call some^moreînit;
call check(base);
call timestamp(start^time);
!set starting time
records^read := 0;
records^written := 0;
Issue and complete I/O requests. Every 30 seconds, report how many frames have
been read and written.
while session do
begin
call postîos;
case nextêvent(timeôut) of
begin
!0! call frameîn;
!1! call frameôut;
!2! call timedôut;
!3! begin
sbuf[9]':='"??? Dangling CNTRL-SABM or READ TAG invalid"->@ptr;
call writeêrr^msg;
end;
otherwise call debug;
end;
call seeîf^30^seconds^has^passed;
end;
end;
end;
B–32
Appendix C
ADCCP Programming Example
Using C
This appendix contains a sample application written in the C programming language.
The example opens a line, makes a (1) SET CONFIGURATION request, then closes the
line after printing a message based on the status code returned by the SET
CONFIGURATION response.
/*
*-------------------------------------------------------------------*
* This is an example for the 6100 ADCCP Programming Manual.
* It opens an ADCCP line, makes a (1) SET CONFIGURATION request,
* then closes the line after printing a message based on the
* status code returned by the SET CONFIGURATION response.
*
*-------------------------------------------------------------------*/
#pragma XMEM
#pragma runnable, inspect, symbols
#include <talh>
nolist
#include <stdlibh> nolist
#include <stringh> nolist
#include <fcntlh> nolist
#include <stdioh> nolist
#include <cextdecs (OPEN,DEVICEINFO,\
FILEINFO,DEBUG,\
ABEND,SETMODE,WRITEREAD)> nolist
extern short Open_line(char *open_name);
extern void Close_line(short rfnum,char *close_name);
extern void Receive(short rfnum,short fcode,short txtout,
short textin,short length,struct message *dPtr);
extern short Set_config(short rfnum);
extern void Status_codes(short code);
struct message {
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
short
short
short
short
short
short
short
short
short
short
short
short
short
short
short
short
short
short
short
short
short
short
short
short
short
function
modifier
request_id
text_out
text_in
MAXFRAME
MODE
AFLDn
EXTENDED
STATIONS
TRANSLATE
RNR_TIMER
XOFFSET
XLENGTH
POLL
SREJ
NOREJ
Reserved
TWA
WINDOW
SWITCHED
HALFDUPLEX
NOCARRFATAL
SWINCARRIER
SWOUTCARRIER
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
1;
1;
1;
1;
1;
1;
1;
1;
1;
1;
1;
2;
1;
1;
1;
1;
1;
1;
1;
1;
1;
1;
1;
1;
1;
C–1
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
unsigned
short
short
short
short
short
short
short
short
short
short
short
short
short
short
short
short
FLAGIDLE
L2RETRY
L1RETRY
THRESHOLD
XFERTIMER
T1TIMER
IDLETIMER
DSRTIMER
ADDRESS
ABMSUPPON
ABMIPON
TESTFRAME
SUPPRESSRR
reserved
OPTIONA
OPTIONB
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
1;
1;
1;
2;
2;
2;
2;
2;
4;
1;
1;
1;
1;
1;
1;
1;
};
main()
{
short refnum;
char line_name[127];
char *xfname;
short status_code;
/*
*
*
*
*
*/
Get the name of the line then open it.
Make a (1) SET CONFIGURATION request
then print out a message based on the status
code returned by the response.
printf("Enter line name: ");
xfname = gets(line_name);
refnum = Open_line(xfname);
status_code = Set_config(refnum);
Status_codes(status_code);
Close_line(refnum,xfname);
}
/*
*----------------------------------------------------------------*
* Set_config
*
*
Makes a (1) SET CONFIGURATION request by calling the Receive
*
function.
*
* Results:
*
*
Returns the status code of the response.
*
* Side effects:
*
*
None.
*
*----------------------------------------------------------------*/
short Set_config(rfnum)
short rfnum;
/* IN - The file number that OPEN
* assigned to the line.
*/
C–2
{
short function_code = 1;
short txt_out = 40;
short txt_in = 0;
short buffer_size;
short status_code;
struct message *setPtr;
lowmem struct message msg = {/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
};
/*
*
*
*
*
*/
Function
Modifier
Request ID
Text Out
Text In
MAXFRAME
MODE
AFLDn
EXTENDED
STATIONS
TRANSLATE
RNR_TIMER
XOFFSET
XLENGTH
POLL
SREJ
NOREJ
Reserved
TWA
WINDOW
SWITCHED
HALFDUPLEX
NOCARRFATAL
SWINCARRIER
SWOUTCARRIER
FLAGIDLE
L2RETRY
L1RETRY
THRESHOLD
XFERTIMER
T1TIMER
IDLETIMER
DSRTIMER
ADDRESS
ABMSUPPON
ABMIPON
TESTFRAME
SUPPRESSRR
reserved
OPTIONA
OPTIONB
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
0,
0,
0,
0,
0,
0x100,
1,
1,
0,
1,
0,
0,
0,
0,
1,
0,
0,
0,
1,
3,
0,
0xff,
0,
1,
0,
0,
3,
3,
0x1f4,
0x64,
0x64,
0x64,
0x12c,
0,
0,
0,
0,
0,
0,
0x01,
0
Assign function code and text in and text out values to request then
assign pointer to be passed to the Receive function, which will use
WRITEREAD to make the request. The status code of the response is
returned to the calling function.
msg.function = function_code;
msg.text_out = txt_out;
msg.text_in = txt_in;
setPtr = &msg;
buffer_size = (short) sizeof(msg);
Receive(rfnum,function_code,txt_out,txt_in,buffer_size,setPtr);
status_code = setPtr->modifier;
C–3
return(status_code);
}
/*
*------------------------------------------------------------------*
* Open_line
*
*
Opens a specified line.
*
* Results:
*
*
Returns the file number OPEN assigns to the line.
*
* Side effects:
*
*
None.
*
*---------------------------------------------------------------------*/
short Open_line(open_name)
char *open_name;
/* IN - pointer to the line name string.
*/
{
struct mask {
unsigned short demountable : 1;
unsigned short audited
: 1;
unsigned short undefined
: 2;
unsigned short type
: 6;
unsigned short subtype
: 6;
};
lowmem
lowmem
short
short
short
short
int
struct mask devtype;
short fname[127];
c_code = 0;
s_code = 0;
reclnth;
rfnum;
error;
/*
* The line name is converted to Guardian format, and the line is checked
* to make sure it's an ADCCP line. If it is, the line is opened and
* the file number for the line is returned to main.
*/
s_code = extfname_to_intfname(open_name,fname);
if (s_code != 0) {
printf("Error with external-to-internal filename conversion.\n");
DEBUG();
}
DEVICEINFO(fname,&devtype,&reclnth);
if (devtype.type != 51 || devtype.subtype != 2) {
printf("%d is not a 6100 ADCCP line.\n",fname);
DEBUG();
ABEND();
}
c_code = OPEN(fname,(short *)&rfnum,14);
printf("OPEN ERROR %d on 1st open.\n",error);
DEBUG();
ABEND();
}
else SETMODE(rfnum,20,1);
C–4
return(rfnum);
}
/*
*----------------------------------------------------------------* Close_line
*
*
Closes the line that the Open_line function opened.
*
* Results:
*
*
Closes the line specified by the file number returned
*
from an OPEN.
*
* Side effects:
*
*
None.
*------------------------------------------------------------------*/
void Close_line(file_number,close_name)
short file_number;
/* IN - file number from OPEN.
*/
char *close_name;
/* IN - Name of line closed.
*/
{
CLOSE(file_number);
printf("Line %s closed.\n",close_name);
}
/*------------------------------------------------------------------*
* Receive
*
*
Makes the ADCCP request/response.
*
* Results:
*
*
Calls WRITEREAD and puts the specified message in the
*
WRITEREAD buffer.
*
* Side effects:
*
*
Changes the contents of the WRITEREAD buffer to whatever
*
dPtr points to.
*
*-------------------------------------------------------------------*/
short rfnum;
* Open_line.
*/
*/
short textout;
*/
short textin;
short length;
/*
*
*/
/*
*
*
*/
IN - length of the WRITEREAD buffer
{
short c_code = 0;
C–5
short count;
short count_trans;
int error;
/*
*/
dPtr->function =
dPtr->modifier =
dPtr->request_id
dPtr->text_out =
dPtr->text_in =
function_code;
0;
= function_code;
textout;
textin;
count = length;
DEBUG();
ABEND();
}
}
/*
*------------------------------------------------------------------*
* Status_codes
*
*
Prints the meaning of the status code returned by
*
the response.
*
* Results:
*
*
Takes the status code from the response and prints out
*
a message.
*
* Side effects:
*
*
None.
*--------------------------------------------------------------------*/
void Status_codes(code)
short code;
/* IN - The status code value from the response.
*/
{
switch(code) {
case 0:
printf("Status code %d.\n",code);
printf("The request was successful.\n");
break;
case 1:
printf("A bad sequence number in a frame in route from a");
printf("controller to an LIU.\n");
break;
case 2:
printf("The LIU received the wrong sequence of frame types");
printf("from the controller.\n");
break;
case 3:
printf("The LIU received an invalid frame type from the controller.\n");
case 4:
C–6
printf("There is no room for the request frame on the LIU.\n");
break;
case 5:
printf("Addressing error (invalid task ID) occurred in the controller.");
break;
case 6:
printf("A resource shortage occurred in the controller.");
break;
case 8:
printf("Too many of these requests are already queued.\n");
break;
case 9:
printf("The request is invalid for the current station state.\n");
break;
case 10:
printf("Invalid Function or Modifier value of the request.\n");
break;
case 11:
printf("The request ID is not in the range 1 through 32767.\n");
break;
case 12:
printf("Value in the Text Out field does not match the actual");
printf("length of the Text field.\n");
break;
case 13:
printf("Value in the Text In field is not sufficient for operation.\n");
break;
case 14:
printf("The station ID is undefined or invalid.\n");
break;
case 15:
printf("A value in the Text field is invalid.\n");
break;
case 18:
printf("Insufficient resources to perform function.\n");
break;
case 24:
printf("An application issued a STOP OPERATION request.\n");
printf("All stations are now DEAD. All pending requests are aborted.\n");
break;
case 25:
printf("An application issued a MODE SET request to this station\n");
printf("or received a mode setting command from the remote station.\n");
printf("Pending data transfers for the station are aborted.\n");
break;
case 26:
printf("Remote primary station sent a mode-setting frame ");
printf("to this station.\n");
printf("Pending data transfers for the station are aborted.\n");
break;
case 27:
printf("A request failed after the allowed number of retries.\n");
break;
C–7
case 28:
printf("A request failed after the allowed number of retries.\n");
printf("The station is DEAD and in ERRORSTOP condition.\n");
break;
case 29:
printf("A new request replaced the one in progress.\n");
break;
case 30:
printf("RNR condition lasted too long.\n");
break;
case 31:
printf("SENDTEXT received as a response and No_RNR_Retry option\n");
printf("selected or No_SRNR_Retry is selected and the local station ");
printf("sent RNR.\n");
break;
case 32:
printf("The modem reset the DSR signal, disconnecting the line.\n");
break;
case 33:
printf("The modem reset the transmit clock, disconnecting the line.\n");
break;
case 34:
printf("The modem reset the DCD signal unexpectedly.\n");
break;
case 35:
printf("The modem reset the CTS signal unexpectedly.\n");
break;
case 36:
printf("The modem did not assert DSR within the expected time\n");
printf("interval,or did not drop DSR within the expected time");
printf("interval.\n");
break;
case 39:
printf("DSR came up (V.25 only - V.25 terminated).\n");
break;
case 40:
printf("The remote station did not respond to an information frame.\n");
break;
case 41:
printf("An input frame exceeded the maximum length defined");
printf("for the line.\n");
break;
case 42:
printf("An input frame had an invalid C-field.\n");
break;
case 43:
printf("An I-field was present in an input frame that");
printf("should not have contained one.\n");
break;
case 44:
printf("The Nr value in an incoming frame acknowledged a ");
printf("frame that had not yet been sent.\n");
break;
case 45:
C–8
printf("Specified Poll Cycles done.\n");
break;
case 64:
printf("UI frame received.\m");
break;
case 65:
printf("RIM-Primary, SIM-secondary.\n");
break;
case 66:
printf("USER0 frame received.\n");
break;
case 67:
printf("DM-primary, SARM-secondary.\n");
break;
case 68:
printf("UP frame received, secondary.\n");
break;
case 69:
printf("Invalid frame received.\n");
break;
case 70:
break;
case 71:
printf("SABM frame received, secondary.\n");
break;
case 72:
printf("Remote station initialized DISC sequence.\n");
break;
case 73:
break;
case 74:
break;
case 75:
printf("SARME-Secondary only.\n");
break;
case 76:
printf("UA frame received, primary.\n");
break;
case 77:
break;
case 78:
break;
case 79:
printf("SABME received, secondary.\n");
break;
case 80:
printf("A SNRM arrived. The link is in NRM.\n");
C–9
break;
case 81:
printf("FRMR-Primary, RSPR-Secondary.\n");
break;
case 82:
break;
case 83:
printf("RSET frame received, secondary.\n");
break;
case 84:
break;
case 85:
break;
case 86:
break;
case 87:
printf("XID frame received.\n");
break;
case 88:
break;
case 89:
break;
case 90:
break;
case 91:
printf("A SNRM arrived. The line is now NRME.\n");
break;
case 92:
printf("TEST frame received.\n");
break;
case 128:
printf("The arriving frame had the poll/final bit on.\n",code);
break;
default:
printf("Unexpected status code.\n");
}
}
C–10
Appendix D
ASCII to EBCDIC Code
Conversion
Tandem systems translate ASCII code to EBCDIC code, and EBCDIC code to ASCII
code as shown in Table D-1. The octal number and hexadceimal equivalent values are
given for each character or mnemonic.
Table D-1. ASCII-to-EBCDIC and EBCDIC-to-ASCIICode Conversion (Page 1 of 8)
ASCII to EBCDIC
ASCII
EBCDIC to ASCII
EBCDIC
Octal
Hex
000
001
002
003
004
005
006
007
010
011
012
013
014
015
016
017
020
021
022
023
024
025
026
027
030
031
00
01
02
03
04
05
06
07
08
09
0A
0B
0C
0D
0E
0F
10
11
12
13
14
15
16
17
18
19
Char
NUL
SOH
STX
ETX
EOT
ENQ
ACK
BEL
BS
HT
LF
VT
FF
CR
SO
SI
DLE
DC1
DC2
DC3
DC4
NAK
SYN
ETB
CAN
EM
EBCDIC
Octal
Hex
000
001
002
003
067
055
056
057
026
005
045
013
014
015
016
017
020
021
022
023
074
075
062
046
030
031
00
01
02
03
37
2D
2E
2F
16
05
25
0B
0C
0D
0E
0F
10
11
12
13
3C
3D
32
26
18
19
Char
NUL
SOH
STX
ETX
EOT
ENQ
ACK
BEL
BS
HT
LF
VT
FF
CR
SO
SI
DLE
DC1
DC2
TM
DC4
NAK
SYN
ETB
CAN
EM
ASCII
Octal
Hex
000
001
002
003
004
005
006
007
010
011
012
013
014
015
016
017
020
021
022
023
024
025
026
027
030
031
00
01
02
03
04
05
06
07
08
09
0A
0B
0C
0D
0E
0F
10
11
12
13
14
15
16
17
18
19
Char
NUL
SOH
STX
ETX
PF
HT
LC
DEL
SMM
VT
FF
CR
SO
SI
DLE
DC1
DC2
TM
RES
NL
BS
IL
CAN
EM
Octal
Hex
000
001
002
003
234
011
206
177
227
215
216
013
014
015
016
017
020
021
022
023
235
205
010
207
030
031
00
01
02
03
9C
09
86
7F
97
8D
8E
0B
0C
0D
0E
0F
10
11
12
13
9D
85
08
87
18
19
Char
NUL
SOH
STX
ETX
HT
DEL
VT
FF
CR
SO
SI
DLE
DC1
DC2
DC3
BS
CAN
EM
D–1
ASCII to EBCDIC Code Conversion
Table D-1. ASCII-to-EBCDIC and EBCDIC-to-ASCIICode Conversion(Page 2 of 8)
ASCII to EBCDIC
ASCII
EBCDIC to ASCII
EBCDIC
EBCDIC
ASCII
Octal
Hex
Char
Octal
Hex
Char
Octal
Hex
Char
Octal
Hex
032
033
034
035
036
037
040
041
042
043
044
045
046
047
050
051
052
053
054
055
056
057
060
061
062
063
064
065
066
067
070
071
1A
1B
1C
1D
1E
1F
20
21
22
23
24
25
26
27
28
29
2A
2B
2C
2D
2E
2F
30
31
32
33
34
35
36
37
38
39
SUB
ESC
FS
GS
RS
US
SP
!
QUO
#
$
%
&
'
(
)
*
+
,
.
/
0
1
2
3
4
5
6
7
8
9
077
047
034
035
036
037
100
117
T177
173
133
154
120
175
115
135
134
116
153
140
113
141
360
361
362
363
364
365
366
367
370
371
3F
27
1C
1D
1E
1F
40
4F
7F
7B
5B
6C
50
7D
4D
5D
5C
4E
6B
60
4B
61
F0
F1
F2
F3
F4
F5
F6
F7
F8
F9
SUB
ESC
IFS
IGS
IRS
IUS
SP
vbar
QUOT
#
$
%
&
'
(
)
*
+
,
.
/
0
1
2
3
4
5
6
7
8
9
032
033
034
035
036
037
040
041
042
043
044
045
046
047
050
051
052
053
054
055
056
057
060
061
062
063
064
065
066
067
070
071
1A
1B
1C
1D
1E
1F
20
21
22
23
24
25
26
27
28
29
2A
2B
2C
2D
2E
2F
30
31
32
33
34
35
36
37
38
39
CC
CU1
IFS
IGS
IRS
IUS
DS
SOS
FS
222
217
034
035
036
037
200
201
202
203
204
012
027
033
210
211
212
213
214
005
006
007
220
221
026
223
224
225
226
004
230
231
92
8F
1C
1D
1E
1F
80
81
82
83
84
0A
17
1B
88
89
8A
8B
8C
05
06
07
90
91
16
93
94
95
96
04
98
99
D–2
BYP
LF
ETB
ESC
SM
CU2
ENQ
ACK
BEL
SYN
PN
RS
UC
EOT
Char
FS
GS
RS
US
LF
ETB
ESC
ENQ
ACK
BEL
SYN
EOT
ASCII to EBCDIC
ASCII
EBCDIC to ASCII
EBCDIC
EBCDIC
ASCII
Octal
Hex
Char
Octal
Hex
Char
Octal
Hex
072
073
074
075
076
077
100
101
102
103
104
105
106
107
110
111
112
113
114
115
116
117
120
121
122
123
124
125
126
127
130
131
3A
3B
3C
3D
3E
3F
40
41
42
43
44
45
46
47
48
49
4A
4B
4C
4D
4E
4F
50
51
52
53
54
55
56
57
58
59
:
;
<
=
>
?
@
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
172
136
114
176
156
157
174
301
302
303
304
305
306
307
310
311
321
322
323
324
325
326
327
330
331
342
343
344
345
346
347
350
7A
5E
4C
7E
6E
6F
7C
C1
C2
C3
C4
C5
C6
C7
C8
C9
D1
D2
D3
D4
D5
D6
D7
D8
D9
E2
E3
E4
E5
E6
E7
E8
:
;
<
=
>
?
@
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
072
073
074
075
076
077
100
101
102
103
104
105
106
107
110
111
112
113
114
115
116
117
120
121
122
123
124
125
126
127
130
131
3A
3B
3C
3D
3E
3F
40
41
42
43
44
45
46
47
48
49
4A
4B
4C
4D
4E
4F
50
51
52
53
54
55
56
57
58
59
Char
CU3
DC4
NAK
SUB
SP
cent
.
<
(
+
vbar
&
Octal
Hex
232
233
024
025
236
032
040
240
241
242
243
244
245
246
247
250
133
056
074
050
053
041
046
251
252
253
254
255
256
257
260
261
9A
9B
14
15
9E
1A
20
A0
A1
A2
A3
A4
A5
A6
A7
A8
5B
2E
3C
28
2B
21
26
A9
AA
AB
AC
AD
AE
AF
B0
B1
Char
DC4
NAK
SUB
SP
[
.
<
(
+
!
&
D–3
ASCII to EBCDIC
ASCII
EBCDIC to ASCII
EBCDIC
EBCDIC
ASCII
Octal
Hex
Char
Octal
Hex
Char
Octal
Hex
Char
Octal
Hex
Char
132
133
134
135
136
137
140
141
142
143
144
145
146
147
150
151
152
153
154
155
156
157
160
161
162
163
164
165
166
167
170
171
172
5A
5B
5C
5D
5E
5F
60
61
62
63
64
65
66
67
68
69
6A
6B
6C
6D
6E
6F
70
71
72
73
74
75
76
77
78
79
7A
Z
[
\
]
^
_
'
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
351
112
340
132
137
155
171
201
202
203
204
205
206
207
210
211
221
222
223
224
225
226
227
230
231
242
243
244
245
246
247
250
251
E9
4A
E0
5A
5F
6D
79
81
82
83
84
85
86
87
88
89
91
92
93
94
95
96
97
98
99
A2
A3
A4
A5
A6
A7
A8
A9
Z
cent
\
!
not
_
`
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
132
133
134
135
136
137
140
141
142
143
144
145
146
147
150
151
152
153
154
155
156
157
160
161
162
163
164
165
166
167
170
171
172
5A
5B
5C
5D
5E
5F
60
61
62
63
64
65
66
67
68
69
6A
6B
6C
6D
6E
6F
70
71
72
73
74
75
76
77
78
79
7A
!
$
*
)
;
not
/
135
044
052
051
073
136
055
057
262
263
264
265
266
267
270
271
174
054
045
137
076
077
272
273
274
275
276
277
300
301
302
140
072
5D
24
2A
29
3B
5E
2D
2F
B2
B3
B4
B5
B6
B7
B8
B9
7C
2C
25
5F
3E
3F
BA
BB
BC
BD
BE
BF
C0
C1
C2
60
3A
]
$
*
)
;
^
/
D–4
,
%
_
>
?
`
:
,
%
_
>
?
'
:
ASCII to EBCDIC
ASCII
EBCDIC to ASCII
EBCDIC
EBCDIC
ASCII
Octal
Hex
Char
Octal
Hex
Char
Octal
Hex
Char
Octal
Hex
Char
173
174
175
176
177
200
201
202
203
204
205
206
207
210
211
212
213
214
215
216
217
220
221
222
223
224
225
226
227
230
231
232
233
7B
7C
7D
7E
7F
80
81
82
83
84
85
86
87
88
89
8A
8B
8C
8D
8E
8F
90
91
92
93
94
95
96
97
98
99
9A
9B
{
300
152
320
241
007
040
041
042
043
044
025
006
027
050
051
052
053
054
011
012
033
060
061
032
063
064
065
066
010
070
071
072
073
C0
6A
D0
A1
07
20
21
22
23
24
15
06
17
28
29
2A
2B
2C
09
0A
1B
30
31
1A
33
34
35
36
08
38
39
3A
3B
{
173
174
175
176
177
200
201
202
203
204
205
206
207
210
211
212
213
214
215
216
217
220
221
222
223
224
225
226
227
230
231
232
233
7B
7C
7D
7E
7F
80
81
82
83
84
85
86
87
88
89
8A
8B
8C
8D
8E
8F
90
91
92
93
94
95
96
97
98
99
9A
9B
#
@
'
=
QUOT
043
100
047
075
042
303
141
142
143
144
145
146
147
150
151
304
305
306
307
310
311
312
152
153
154
155
156
157
160
161
162
CB
314
23
40
27
3D
22
C3
61
62
63
64
65
66
67
68
69
C4
C5
C6
C7
C8
C9
CA
6A
6B
6C
6D
6E
6F
70
71
72
#
@
'
=
QUOT|
}
~
DEL
}
~
DEL
DS
SOS
FS
BYP
NL
LC
IL
SM
CU2
SMM
CU1
CC
PN
RS
UC
CU3
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
r
313
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
r
CC
D–5
ASCII to EBCDIC
ASCII
EBCDIC
Octal
Hex
234
235
236
237
240
241
242
243
244
245
246
247
250
251
252
253
254
255
256
257
260
261
262
263
264
265
266
267
270
271
272
273
274
275
9C
9D
9E
9F
A0
A1
A2
A3
A4
A5
A6
A7
A8
A9
AA
AB
AC
AD
AE
AF
B0
B1
B2
B3
B4
B5
B6
B7
B8
B9
BA
BB
BC
BD
D–6
EBCDIC to ASCII
Char
EBCDIC
Octal
Hex
004
024
076
341
101
102
103
104
105
106
107
110
111
121
122
123
124
125
126
127
130
131
142
143
144
145
146
147
150
151
160
161
162
163
04
14
3E
E1
41
42
43
44
45
46
47
48
49
51
52
53
54
55
56
57
58
59
62
63
64
65
66
67
68
69
70
71
72
73
Char
PF
RES
ASCII
Octal
Hex
234
235
236
237
240
241
242
243
244
245
246
247
250
251
252
253
254
255
256
257
260
261
262
263
264
265
266
267
270
271
272
273
274
275
9C
9D
9E
9F
A0
A1
A2
A3
A4
A5
A6
A7
A8
A9
AA
AB
AC
AD
AE
AF
B0
B1
B2
B3
B4
B5
B6
B7
B8
B9
BA
BB
BC
BD
Char
~
s
t
u
v
w
x
y
z
Octal
Hex
315
316
317
320
321
176
163
164
165
166
167
170
171
172
322
323
324
325
326
327
330
331
332
333
334
335
336
337
340
341
342
343
344
345
CD
CE
CF
D0
D1
7E
73
74
75
76
77
78
79
7A
D2
D3
D4
D5
D6
D7
D8
D9
DA
DB
DC
DD
DE
DF
E0
E1
E2
E3
E4
E5
Char
~
s
t
u
v
w
x
y
z
ASCII to EBCDIC
ASCII
EBCDIC to ASCII
EBCDIC
Octal
Hex
276
277
300
301
302
303
304
305
306
307
310
311
312
313
314
315
316
317
320
321
322
323
324
325
326
327
330
331
332
333
334
335
336
337
BE
BF
C0
C1
C2
C3
C4
C5
C6
C7
C8
C9
CA
CB
CC
CD
CE
CF
D0
D1
D2
D3
D4
D5
D6
D7
D8
D9
DA
DB
DC
DD
DE
DF
Char
EBCDIC
Octal
Hex
164
165
166
167
170
200
212
213
214
215
216
217
220
232
233
234
235
236
237
240
252
253
254
255
256
257
260
261
262
263
264
265
266
267
74
75
76
77
78
80
8A
8B
8C
8D
8E
8F
90
9A
9B
9C
9D
9E
9F
A0
AA
AB
AC
AD
AE
AF
B0
B1
B2
B3
B4
B5
B6
B7
Char
ASCII
Octal
Hex
Char
Octal
Hex
Char
276
277
300
301
302
303
304
305
306
307
310
311
312
313
314
315
316
317
320
321
322
323
324
325
326
327
330
331
332
333
334
335
336
337
BE
BF
C0
C1
C2
C3
C4
C5
C6
C7
C8
C9
CA
CB
CC
CD
CE
CF
D0
D1
D2
D3
D4
D5
D6
D7
D8
D9
DA
DB
DC
DD
DE
DF
346
347
{
A
B
C
D
E
F
G
H
I
E6
E7
173
101
102
103
104
105
106
107
110
111
350
351
352
353
354
355
175
112
113
114
115
116
117
120
121
122
356
357
360
361
362
363
7B
41
42
43
44
45
46
47
48
49
E8
E9
EA
EB
EC
ED
7D
4A
4B
4C
4D
4E
4F
50
51
52
EE
EF
F0
F1
F2
F3
{
A
B
C
D
E
F
G
H
I
}
J
K
L
M
N
O
P
Q
R
}
J
K
L
M
N
O
P
Q
R
D–7
ASCII to EBCDIC
ASCII
EBCDIC
Octal
Hex
340
341
342
343
344
345
346
347
350
351
352
353
354
355
356
357
360
361
362
363
364
365
366
367
370
371
372
373
374
375
376
377
E0
E1
E2
E3
E4
E5
E6
E7
E8
E9
EA
EB
EC
ED
EE
EF
F0
F1
F2
F3
F4
F5
F6
F7
F8
F9
FA
FB
FC
FD
FE
FF
D–8
EBCDIC to ASCII
Char
EBCDIC
Octal
Hex
270
271
272
273
274
275
276
277
312
313
314
315
316
317
332
333
334
335
336
337
352
353
354
355
356
357
372
373
374
375
376
377
B8
B9
BA
BB
BC
BD
BE
BF
CA
CB
CC
CD
CE
CF
DA
DB
DC
DD
DE
DF
EA
EB
EC
ED
EE
EF
FA
FB
FC
FD
FE
FF
Char
ASCII
Octal
Hex
340
341
342
343
344
345
346
347
350
351
352
353
354
355
356
357
360
361
362
363
364
365
366
367
370
371
372
373
374
375
376
377
E0
E1
E2
E3
E4
E5
E6
E7
E8
E9
EA
EB
EC
ED
EE
EF
F0
F1
F2
F3
F4
F5
F6
F7
F8
F9
FA
FB
FC
FD
FE
FF
Char
\
S
T
U
V
W
X
Y
Z
0
1
2
3
4
5
6
7
8
9
Octal
Hex
134
237
123
124
125
126
127
130
131
132
364
365
366
367
370
371
060
061
062
063
064
065
066
067
070
071
372
373
374
375
376
377
5C
9F
53
54
55
56
57
58
59
5A
F4
F5
F6
F7
F8
F9
30
31
32
33
34
35
36
37
38
39
FA
FB
FC
FD
FE
FF
Char
\
S
T
U
V
W
X
Y
Z
0
1
2
3
4
5
6
7
8
9
Glossary
ABM. See Asynchronous Balanced Mode (ABM).
ADCCP. See Advanced Data Communications Control Procedures (ADCCP).
address field. The field immediately following the starting flag in a bit-synchronous
frame. This field always identifies the secondary station that is communicating with
the primary station. Generally, the address field is 1 byte long; however, in extended
address mode the address field can be up to 4 bytes long. Extended address fields are
not supported by the SDLC protocol standard.
Advanced Data Communications Control Procedures (ADCCP). This is the general standard
for bit-synchronous protocols. It includes two major modes of operation:
Asynchronous Balanced Mode (ABM) and Normal Response Mode (NRM). ADCCPABM is analogous to high-level data link control (HDLC), and ADCCP-NRM is
analogous to synchronous data-link control (SDLC). See also Asynchronous Balanced
Mode, Normal Response Mode, and Asynchronous Response Mode.
American National Standard Code for Information Interchange (ASCII). A method of coding
data, consisting of 7 bits for each character plus a parity bit. Designed for synchronous
or asynchronous use, the code has 128 standard characters.
ARM. See Asynchronous Response Mode (ARM).
ASCII. See American National Standard Code for Information Interchange (ASCII).
Asynchronous Balanced Mode (ABM). A mode of communications whereby two combined
stations communicate on a point-to-point link. Either or both stations can issue
commands to set up or dissolve the link. During data transmission, the stations
function as peers. This mode is also used by the high-level data-link control (HDLC)ABM protocol.
Asynchronous Response Mode (ARM.). A mode of communications in which the
secondary station may initiate transmission without receiving explicit permission from
the primary station.
backplane interconnect card (BIC). A card that plugs into back of a CLX or Cyclone
system providing the physical interface between an I/O controller and the outside
devices.
BIC. See backplane interconnect card (BIC).
bit-synchronous. A class of serial communications protocols for data-link control. This
class includes ADCCP, high-level data-link control (HDLC), and synchronous datalink control (SDLC) protocols. Many wide-area network architectures define a bitsynchronous protocol as the standard link-level protocol.
broadcast station. A station with an address any and all stations can send to. All
stations can send to a station that has an ID of 0.
CCITT. Comité Consultatif International Télégraphique et Téléphonique (International
Telegraph and Telephone Consultative Committee). A standards-setting group for
international telephone carriers.
Glossary–1
Glossary
CIU. See communication interface unit (CIU).
clear to send (CTS ). A signal that comes from a modem, indicating to the computer that
the modem is ready to accept data for transmission.
CLIP. See communications line interface processor (CLIP).
CMI. See Communications Management Interface (CMI).
communication interface Unit (CIU). The proper term used for the 6100/3650 family of
controllers. There can be two of these programmable I/O controllers in each 6100 CSS
or 3650 CSS; the CIUs connect the host with the rest of the 6100 communications
subsystem (CSS) or 3650 CSS. These CIUs are another fault-tolerant Tandem
enhancement: if one of the CIUs fails, the other takes over.
Communications Subsystem Manager (CSM).. A software process within the CPU that
coordinates certain functions within the 6100 subsystem. Among other things, the
CSM can load special microcode into the communications interface units (CIU) and
communications line interface processors (CLIP). The CSM also monitors the physical
environment of the 6100 CSS.
communications line interface processor (CLIP). The CLIP is part of the line interface unit
(LIU) within the 6100/3650 family of controllers. The CLIP is a programmable
processor that provides a link-level protocol and a software interface to the host. The
CLIP does some of the work that the host-resident communication processes used to
handle. CLIP software implements specific communications protocols such as
advanced data communications control procedures (ADCCP) or TINET.
communications management interface (CMI). The CMI, together with its server process,
the communications management process (CMP), provides the main operator interface
to CP6100. Through CMI, a user can issue commands to change the subsystem
configuration or inquire about the characteristics and status of lines.
control field. The field following the address field in a bit-synchronous frame.
It contains bit-encoded commands and responses and can also contain frame sequence
numbers. The contents of the control field indicate whether the frame has an
information, supervisory, or unnumbered format. Generally, this field is 1 octet long;
however, in extended mode, the control field can be 2 octets long.
CSM. See Communications Subsystem Manager.(CSM).
CTS . See clear to send (CTS).
data carrier detect (DCD). A signal that comes from a modem indicating that a data
carrier is being received. On half duplex channels, this signal is off whenever RTS is
on.
data set ready (DSR). The signal sent by a modem to the line informing the calling DCE
that the unit received a DTR signal from the associated DTE.
data-circuit terminating equipment (DCE). Generally refers to the modem to which a
terminal or host computer (called the DTE) is connected.
Glossary–2
Glossary
data-terminal equipment (DTE). DTE is the terminal or host computer to which a modem
(called the data-terminal equipment, or DCE) is connected.
DCD. See data carrier detect (DCD).
DCE. See data-circuit terminating equipment (DCE.).
DISC. See disconnect (DISC).
disconnect (DISC). A mode-setting command used to inform the addressed
secondary/combined station that the transmitting primary/combined station is
suspending operation with the secondary/combined station.
DSR.. See Data set ready (DSR).
EBCDIC. See Extended binary-coded decimal interchange code (EBCDIC).
exchange identification command. A command used to cause the addressed secondary or
combined station to report its station identification.
Extended binary-coded decimal interchange code (EBCDIC). A method of coding data
designed for synchronous use. It consists of 8 bits of data with no parity bit. EBCDIC
has 256 standard characters.
FCS. See frame-checking sequence (FCS).
flag. For frame formats, the flag is a unique field found at the beginning and end of bitsynchronous frames. The flag is used for synchronization and transparency control.
The value of the flag is always set to the hexadecimal value 7E (01111110).
frame reject (FRMR). In ADCCP, a recovery response used to report an error condition
that is not recoverable by retransmission of the identical frame.
frame-checking sequence (FCS). The field in a bit-synchronous frame that contains the
cyclical redundancy check (CRC) value for the frame. The CRC is used to verify
correct data and is a 16-bit field immediately preceding the ending flag for the frame.
frame. The basic transmission unit within a bit-synchronous communications
environment. Frames are made up of the following fields: beginning flag, address
field, control field, information field, frame-check sequence, and closing flag.
FRMR. See frame reject (FRMR).
full duplex. A method of serial communications in which the data flow between two
points can occur in both directions simultaneously.
Guardian 90 operating system. The main Tandem operating system.
half duplex. A method of serial communications in which the data flow between two
points can occur in only one direction at a time.
HDLC. See High-level Data Link Control (HDLC).
High-level Data Link Control (HDLC). A bit-synchronized data communications protocol
that uses Asynchronous Balanced Mode (ABM) communications between stations.
See also Asynchronous Balanced Mode (ABM).
I-frame. See information frame.
Glossary–3
Glossary
information field. The field in a bit-synchronous frame that contains data or additional
control information. If present, the information field follows the control field and
varies in length.
information frame. A frame format used to pass data between two stations.
LIM. See line interface module (LIM).
line interface module (LIM). The actual connection to the communications line. It
provides the physical and electrical interface to the outside world. The LIM is part of
the line interface unit (LIU) in a 6100 /3650 subsystem.
line interface unit (LIU). A component of the 6100/3650 subsystem. Each LIU supports a
single communications line. There can be up to 15 LIUs in a 6100 subsystem. Each
LIU consists of two parts: a communications line interface processor (CLIP) and a line
interface module (LIM). The LIU is dual-ported to allow it to communicate through
either of the communications interface units (CIUs), providing fault tolerance. (The
LIU does not communicate though both CIUs simultaneously.) See also
communications line interface processor (CLIP) and line interface module (LIM).
LIU. See line interface unit.
multipoint. A data-link configuration in which one station is designated as the
supervisor and controls all communications over the link. The other stations are
designated as tributaries.
nonswitched. A line configuration that provides a permanent path between two
stations. This path can be a privately owned cable or a dedicated path leased from a
common carrier. It is generally a leased line. Contrast with switched.
Normal Response Mode (NRM). A mode of communications within the ADCCP protocol
whereby a secondary station can transmit data only after a request from the primary
station. This mode of operation is also used by synchronous data-link control (SDLC).
NRM. See Normal Response Mode (NRM).
octet. A term used with bit-synchronous frame format. An octet is equivalent to 8 bits
or 1 byte.
path. The route between a specified line interface unit (LIU) and a CPU. Each LIU has
a primary path (Path A) and an alternate path (Path B), both of which are assigned to
different communications interface units (CIUs). The primary and alternate paths
provide fault tolerance if a CIU fails. At system generation, a group of lines in a 6100
CSS can be assigned to each path.
point-to-point. A non-multidropped, unshared data-link configuration between two
stations. This configuration can exist between a primary and a secondary station or
between two combined stations.
primary. In an SDLC or ADCCP-NRM configuration, the primary station initiates a
data transfer and is in control during the exchange of messages. It notifies each
secondary link station when the station can transmit data and when the station should
expect to receive data. See also secondary.
Glossary–4
Glossary
REJ. See Reject (REJ).
Reject (REJ). In the ADCCP protocol, a supervisory format command used by a station
to request the retransmission of I-frames starting from a specified frame.
request to send (RTS). A signal from the host computer or terminal (DTE) to the modem
(DCE) requesting permission to transmit data. Permission is granted when the
modem turns CTS to ON.
RR. Receiver Ready (RR). A supervisory type of frame.
RR. See Receiver Ready (RR).
RS-232. An industry standard for serial data transmission. It describes pin
assignments (for a 25-pin connector), signal functions, and electrical characteristics.
RS-232D is the current standard.
RS-449. An industry standard for serial data transmission that allows higher data
signalling rates and a longer distance between data terminal equipment (DTE) and
data communications equipment (DCE) than does RS-232C. RS-499 data signalling
rates can be up to 2 Mbits per second, and the cable distance can be up to up to 200 feet
between the DTE and DCE. Longer distances are also possible at lower data rates.
RS-449 is compatible with RS-232C. The RS-449 standard also provides for future
compatibility with X.21. V.10 and V.11 are electrical-interface standards used in
Europe that are analogous to RS-449.
RTS . See request to send (RTS).
S-frame. See supervisory frame.
SABM. See Set Asynchronous Balanced Mode (SNRM).
SDLC. See synchronous data-link control (SDLC).
secondary. The station contacted by the primary station and controlled by the primary
message in a message exchange. The secondary station cannot initiate a
communication. Contrast with primary.
Selective Reject (SREJ). In the ADCCP protocol, a supervisory format command used by
a station to request transmission of a single specified I-frame.
Set Asynchronous Balanced Mode (SNRM). In ADCCP Asynchronous Balanced Mode
(ABM) and high-level data-link control (HDLC), the unnumbered frame sent by one
station to establish a data link with another station.
Set Initialization Mode (SIM). In the ADCCP protocol, a mode-setting command used to
cause a secondary or a combined station to initiate a station-specified procedure in
order to initialize its link level control functions.
Set Normal Response Mode (SNRM). The unnumbered frame sent by the primary station
to the secondary station to establish the data link.
SIM. See Set Initialization Mode (SIM).
SNRM. See Set Normal Response Mode (SNRM).
Glossary–5
Glossary
SREJ. See Selective Reject (SREJ).
station. An independently controllable configuration of data terminal equipment
(DCE) from or to which messages are transmitted on a data link.
supervisor. The controlling station in a centralized multipoint data link.
supervisory frame. A frame format used to convey READY or BUSY status or to request
retransmission when an error is detected.
switched. A line configuration for circuit-switched networks such as a public
telephone network. Contrast with switched.
synchronous data-link control (SDLC). One of the bit-synchronous communications
protocols. It uses Normal Response Mode (NRM) operation. SDLC is the protocol
used in Systems Network Architecture (SNA) networks.
synchronous. A general class of data communications that includes ADCCP, Bisync,
synchronous data-link control (SDLC), and high-level data-link control (HDLC)
protocols. It is the opposite of asynchronous communications. In synchronous
transmission, the sending and receiving are controlled by timing signals. Also, a flag,
SYN, or other character is used instead of a start-stop bit.
SYSGEN. The system generation program that is run against a CONFTEXT file (which
describes a Guardian 90 system configuration) and that generates a systemcustomized version of the Guardian 90 operating system. The SYSGEN program is
usually invoked by the INSTALL program.
U-frame. See unnumbered frame.
unnumbered frame. A frame format used to pass data-link management commands and
responses between the primary and the secondary stations.
unnumbered poll frame. A command frame used to solicit response frames from
secondary stations or a combined station. Secondary or combined station that receives
a UP-frame with the poll bit set respond with a frame that has the final bit set.
Secondary and combined stations respond to a frame without the final bit set with a
UP-frame without the poll bit set whenever they have I-frames or UI frames to send,
accepted but not acknowledged an I-frame, or have an unreported change of condition
or status, or have a status to report.
UP-frame. See unnumbered poll frame.
V.25 bis. A CCITT recommendation for a protocol for setting up a data connection with
a serial modem that has automatic calling capability on the general, switched
telephone network.
V.35. A CCITT recommendation for a wide-band, 48-kbits-per-second modem. V.36
modems, which have electrical interface characteristic equivalent to RS-449, replaces
V.35.
window size. The maximum number of I-frames that can be sent without
acknowledgment.
XID. See exchange identification command.
Glossary–6
Glossary
X.21. A CCITT recommendation that specifies the physical and functional interface
between data-terminal equipment (DTE) and data circuit-terminating equipment
(DCE) for synchronous operation on circuit-switched public data networks.
Glossary–7
Index
6100 ADCCP 3-3, 5-1
A
ABM
See line control modes
abort sequence
See frames
acknowledgment 1-16, 4-21
ADCCP 3-2, 4-19, 4-21, 4-22, 5-1, 6-29, 6-39
state changes 3-14
ADCCP commands 1-11
See also command codes
See also frames
format 1-11
information 1-11
supervisory 1-11
unnumbered 1-11
UP 6-25
ADCCP protocol 1-17, 2-1, 2-3, 2-12, 3-1, 3-3, 3-13, 3-14, 3-15
definition 1-1
ADCCP protocol module 1-1, 1-11, 1-17, 2-1, 2-6, 2-8, 2-11, 2-12, 2-13,
2-16, 3-1, 3-2, 3-3, 6-1, 6-16, 6-18
ADCCP/X21 3-1, 3-2, 3-3, 3-6, 3-14, 6-40, 6-44, 6-46
configuration
ACCEPT CHARGES 3-4
CIRCUIT-SWITCHED 3-4
CPS ACTION TABLE 3-5
NOT READY STATE 3-6
RETRY INTERVAL 3-6
RETRY MAXIMUM 3-6
ADCCP/X21 architecture 3-2
ADCCP/X21 circuits 3-15
ADCCP/X21 protocol module 6-44, 6-49
address
primary stations 2-14
remote stations 2-14
address field 1-2
See also frames
Index–1
Index
addresses 1-9, 2-3
See also stations
abbreviated 3-1, 3-12
abbreviated signal 5-3
full 3-1, 3-12
full signal 5-3
length 2-17
primary stations 2-14
transfer 3-12
X.21 5-3
addressing
principles of 1-9
application 1-1
See also program
requests 1-10
application data 1-8, 1-17
application process 4-9
application request
See requests
applications 1-10, 1-16, 1-18, 2-1, 2-5, 2-6, 2-10, 2-11, 2-18, 3-10, 4-20
combined 6-25
design 2-16
local 4-21
multiple 4-24
primary 6-25
process 2-1
request retry 4-6
requests 2-1, 2-3, 2-4, 2-6
tasks
See tasks
applications response
See responses
ARM
ASCII 1-3
See also translation
asynchronous messages 4-12, 4-19, 4-27, 5-2
See also asynchronous responses
See also responses
Index–2
Index
asynchronous responses 4-27
AUTOCONF parameter 4-13
B
backup process 4-6
bit stream 3-1
buffer space 2-1, 2-18
buffers 2-16
input 2-17
output 2-17
size
calculation of 2-17
C
call attempts 3-6
call clearing procedures 3-3
call control procedures 3-15, 3-12
call control task 3-2, 3-3
inactive 3-3
call establishment 3-5
clear 3-6
retry 3-6
X.21 3-3
call establishment procedures 3-10, 3-13
call initiation 3-10
call progress signals (CPS) 3-1, 3-5, 3-6, 3-13
call request 3-10
call requests 3-1, 3-12
call retry 3-6
calls
charges 5-3
clearing 6-49
direct 3-1, 6-45
selective 6-46
establishment 5-3, 5-6, 6-45
identification 5-4
incoming 3-1, 3-10, 3-13, 5-3, 6-44
normal 3-1
Index–3
Index
calls (continued)
outgoing 5-3, 6-44, 6-45
direct 6-44
selective direct 6-44
progress signal 6-46
redirection 5-3
request 6-45
selective 3-1
unsuccessful 3-1
calls establishment 3-13
calls progress signals 5-3
cancel 4-25
pending data transfers 4-25
CCITT 3-1, 3-3, 3-7, 3-12, 5-2, 5-4
CCITT recommendation X.21 3-1
CHANGELIST request 2-6
character code translation 1-17
characters
truncation 4-8
charging information 3-1, 3-14, 3-15
circuits
leased lines 3-15
X.21 5-2
clearing 5-5
CLIP 1-1, 3-1, 3-10
CMI 1-10, 2-5, 2-8, 2-18, 5-2, 6-11, 6-20
TRACE facility 6-11, 6-12, 6-20
combined stations
See stations
command codes 1-15
See also response codes
acknowledgements 4-20
DISC 1-15, 1-16, 2-16, 4-20, 5-5
DM 1-15, 2-15, 2-16
FRMR 1-15
REJ 1-13, 1-15
RESET 1-15
RNR 1-13, 1-15
RR 1-13, 1-15
SABM 1-16
SABME 1-16
SARM 1-16, 4-20
Index–4
Index
command codes (continued)
SARME 1-16
SIM 1-16
SNRM 1-16, 2-15, 4-20
SNRME 1-16
SREJ 1-13, 1-15
TEST 1-16
UA 2-15
UP 6-25
XID 1-17
commands 1-15, 2-3, 2-6
See ADCCP commands
DISC 4-22
mode-setting 6-29
SNRM 4-20
SABM 4-20
unnumbered 2-8
communications lines 1-4
communications 4-1
Communications Line Interface Unit
See CLIP
communications subsystem 1-1, 3-1
completion
normal 4-26
completion code 3-15
condition codes 4-26
non-zero 4-12, 4-23
conditions
See also stations
abnormal 4-10
ERRORSTOP 6-29, 6-30, 6-35, 6-39
NOPOLL 6-35
RNR 6-35
configuration 1-15, 2-5
See also SYSGEN parameters
line options 1-18, 5-2
X.21 5-2
lines 1-4, 3-3, 4-13
options
ADCCP 3-3
Index–5
Index
configuration (continued)
parameters 4-18
X.21 6-42
SYSGEN 4-13
X.21
ADCCP character code translation 3-3
ADCCP frame format 3-3
ADCCP transmission control 3-3
attributes 3-3
call control task 3-3
clearing phase 3-3
connection establishment 3-3
error handling 3-3
configuration block 2-16, 4-24, 6-2, 6-9
format 6-2/3
X.21 5-2, 6-40, 6-42/43
configuration file 6-2
connections 6-44, 6-46, 6-47, 6-49
See also X.21
circuit-switched 3-1, 3-15
cleared 3-1
clearing 5-6
causes 3-14
establishment 3-2, 3-3, 3-10, 3-13, 5-4, 5-5
call progress signals 3-13
called address 3-13
calling address 3-13
initiation 5-3
leased 3-1
network 3-3
release 3-3
releasing 5-4
switched 3-1, 6-31
X.21 5-5
set-up 3-3
control block 2-6, 2-16, 2-17
control field
See also Nr parameter
See also Ns parameter
See also poll/final bit
See frames
Index–6
Index
control field (continued)
extended 1-2
length 2-17
control information 1-8, 1-17
controllers
token ring 2-15
CP6100 3-3, 4-6, 4-19
CP6100 I/O 2-1
CPS Action Table 3-5/6
classes 3-5
Clear 3-6
No Action 3-6
Retry 3-6
Cyclic Redundancy Check (CRC) 1-17
D
data 6-26
exchanging 5-5
rate 1-3
receiving 2-1, 4-12, 4-21, 5-5
X.21 5-1
requests 2-13
sending 2-1, 5-5
transfer 3-1
transferring 3-3, 4-1, 4-25, 5-2, 6-16
data circuit-terminating equipment (DCE) 3-1
data communications lines 1-1
data terminal equipment (DTE) 3-1
data transfer 3-2, 3-14, 3-15
DCE 3-6, 3-8, 3-10, 3-13, 3-14, 3-15, 5-2, 5-3, 5-4, 5-6, 6-44, 6-46, 6-49
disconnects 5-5
DCE circuits
byte timing 3-8
indications 3-8
receive 3-8
signal element timing 3-8
DCE signals 3-10/12
debug 2-18
device-type parameter
See procedure calls
devices 1-4
Index–7
Index
DISC command
See command codes
disconnect 1-15, 2-4, 2-6
See also Disconnect (DISC) command
See also Request Disconnect (RD) response
Disconnect (DISC) command
See command codes
Disconnect Mode (DM) command
See command codes
DISCÎDLE state 2-4, 2-5, 2-6
DISC^WAIT state 2-4, 2-5, 2-6
DM command
See command codes
DM response
See response codes
driver routine 2-1, 2-3
drivers 2-6
control 3-3
initialization 4-19
X.21 3-3, 6-17
DSR signal
See modem control
DTE 3-5, 3-7, 3-8, 3-10, 3-14, 5-2, 6-16, 6-17, 6-44
DTE circuits
control 3-8
transmit 3-8
DTE signals 3-10/12
DTR signal
See modem control
E
EBCDIC 1-3
See also translation
endpoints 3-1
errors 2-10, 4-26, 5-3, 6-26, 6-30, 6-35, 6-39, 6-42/43
codes 3-7
counts 6-13
file-system 4-23, 4-25
handling 1-18, 2-1
hierarchy 4-23
indication 4-9
Index–8
Index
errors (continued)
lines
threshold 4-23
links 2-5
modems 4-24
recoverable 6-29
recovery 4-1, 4-24, 6-31
strategies 4-24, 5-6
SYSGEN parameters 4-24
recovery procedures 4-23
reported to application 4-23
responses 4-23
trapping 4-23, 5-6
types of 4-24
events 2-4
Exchange Station Identification (XID) command
See command codes
extended address field
See frames
extended control
See frames
extended control field
See frames
extended mode
F
facilities
special 6-46
facility
See also X.21
cancellation 5-3
optional 5-3
registration 5-3
request block 5-4
request codes 5-3
request signal 5-4
special 5-3
failures
modems 2-8
Index–9
Index
fields
See frames
address 4-21
control 4-21
information fields 1-16
length 1-15
file management calls 2-1
file management requests
See procedure calls
file-name parameter
See procedure calls
file-system calls 4-23
See procedure calls
files
closure 4-10
open 4-10
final bit 2-12
FLAGIDLE
See SYSGEN parameters
flags 1-18
sequence 1-9
flow control 2-13
frame check sequence (FCS)
See frames
frame handling 2-3
Frame Reject (FRMR) command
See command codes
frame rejects 2-8
frame sequence number 1-14
frames 1-8, 1-15, 2-1, 2-3, 2-4, 2-6, 2-8, 3-14, 4-21, 4-22, 6-13
See also request codes
abort 1-18
abort sequence 1-17
address field 1-8, 1-9, 1-10, 1-11, 1-17
arriving 2-3, 2-11, 6-29
control field 1-8, 1-11, 1-13, 1-14, 1-15
extended 1-13
IBM extended 1-13
definition 1-8
DISC 2-10, 6-25
discarded 2-11
Index–10
Index
frames (continued)
DM 2-8, 6-29
extended address field 1-10
extended control field 1-8
format 1-11, 1-15, 1-18
formats 1-8/18
frame check sequence 1-17
FRMR 2-8, 2-11, 6-25
I-field 4-26
I-frames 1-11, 1-13, 6-23, 6-25
identifier 1-14
IEC 1-13
incoming 2-11, 2-16, 4-22, 6-25, 6-26
information 4-20, 4-21
information field 1-17
information format 1-13
information transmission 1-16
input 2-3, 2-6
invalid 1-15, 4-24
mode-setting 2-8, 2-10, 2-11, 4-20, 4-22, 4-24, 6-29
outgoing 2-16
output 2-6
polling 2-12
queuing 2-6
receiving 6-26
REJ 2-11
reject 2-11
RESET 6-25
response 2-6, 3-14
RIM 2-8, 6-25, 6-29
RNR 2-10, 2-12
RNR polling 2-13
RNR supervisory 2-11
RR 2-12, 2-13
RSET 2-10
RSPR 2-11, 6-25
S-frame 1-11, 1-13, 1-14, 1-15
SABM 2-8, 2-10, 6-25, 6-29
SABME 2-8, 2-10, 6-25, 6-29
SARM 2-8, 2-10, 6-25
SARME 2-8, 2-10, 6-25
SIM 2-8, 2-10, 6-25, 6-29
Index–11
Index
frames (continued)
size 1-18
SNRM 2-8, 2-10
SNRME 2-8, 2-10
SREJ 2-11, 2-16
supervisory format 1-13
TEST 6-23
traces 1-3
transfer 3-13, 3-15, 5-4, 5-5
transmission 4-21, 6-23, 6-24
retry 6-29
types 1-2/3, 1-16
U-frames 1-11, 1-13, 1-15
UA 2-8, 2-10, 6-25, 6-29
UI 6-23, 6-25
unnumbered format 1-13
UP 6-25
USER 6-23, 6-25
user-defined
USER0 1-16
USER1 1-16
USER2 1-16
USER3 1-17
XID 6-23, 6-25
FRMR response
See response codes
H
half duplex 1-14
hardware
problems 2-10
hosts 2-1, 3-1
requests 3-3
I
I-frames 2-3, 2-10, 2-12, 4-20, 4-21
See also frames
discarding 2-11
incoming 2-11
I/O operations 4-9
I/O process 1-1
Index–12
Index
IBM extended control (IEC) field
See frames
idle sequence 3-13, 3-15
IDLETIMER 2-12
IEC
See frames
information field
See frames
Information Transfer State (ITS) 2-7, 2-8
initialization 1-15, 1-16
Initialization State (IS) 2-7, 2-8, 2-10
input frames
See frames
interfaces 3-1
call-controlled 3-1
electrical 1-18
RS-232 1-3, 3-3
RS-449 1-3
V.35 1-3
X.21 3-3, 3-8
circuits 3-8
L
LDS state 2-7
leading zero bit 1-9
leased lines
See lines
Level 1 protocol 2-1, 2-3, 2-6, 3-2, 4-21, 6-11, 6-12
states 2-4
Level 2 protocol 2-1, 2-3, 2-6, 2-7, 2-10, 2-12, 3-2, 4-21, 6-11, 6-12
LIM 1-1, 6-17
X.21 3-1, 3-2
line
opening 4-12
line configuration
See configuration
line control modes 1-4, 1-10, 2-14, 6-29
See also frames
ABM 1-6, 1-7, 1-13, 2-12, 4-17, 4-20, 6-32
ARM 1-6, 1-7, 2-12
extended 1-8, 1-10, 1-13
Index–13
Index
line control modes (continued)
NRM 1-6, 1-13, 2-6, 2-12, 2-13, 4-21, 6-32, 6-37
standard 1-8, 1-13
Line Interface Module
See LIM
Line Interface Unit
See LIU
line overhead 1-9
line quality
statistics 6-13
line states
DISCÎDLE 2-6
DISC^WAIT 2-5, 2-6
READYÎDLE 2-6
XMIT 2-6
lines 2-1, 2-3, 2-6, 2-8, 2-13, 4-6, 4-12, 4-16, 4-20, 4-22, 6-24, 6-49
See also links
activity 6-18
ADCCP 4-1, 5-1
ADCCP/X21 5-2
asynchronous 2-10
circuit switched 5-2
circuit-switched 3-4, 5-4
cleared 5-5
closing 4-1, 5-6
configuration 4-12, 4-13, 6-29
setting parameters 4-16
configuration options 6-2
configuration parameters 4-16
connections 3-4
control mode 4-17
disconnect 2-5, 4-22
disconnecting 4-24
errors 2-8
threshold 4-23
failure 2-10
frame retrieval 6-25
halt activity 6-18
I/O requests 6-18
idle 1-9
leased 1-3, 2-5, 3-4, 4-1, 4-19, 5-2, 5-4, 5-5, 6-16, 6-31
multipoint 1-6, 2-14, 6-32, 6-37
Index–14
Index
lines (continued)
opening 4-2
multiple processes 4-12
X.21 5-1
options 2-16
ADCCP 5-2
X.21 5-2
point-to-point 1-6, 2-14, 6-32
problems 4-23, 6-2
quality 1-18, 2-10, 6-39
quality reports
asynchronous 4-19
starting 4-19
state of 3-2
states
DISCÎDLE 2-4, 2-5
DISC^WAIT 2-4
READYÎDLE 2-4, 2-6
XMIT 2-4, 2-6
stop 4-12
stopping 4-24
switched 1-3, 2-5, 4-1, 5-2, 6-16, 6-17, 6-31
modem control 4-19
troubleshooting 6-13
X.21 3-3
Link Manager 2-1, 3-2
See also Level 2 protocol
links 1-2, 2-1, 2-4, 2-6, 2-8, 2-13, 2-16, 2-17, 3-2, 3-10, 3-13, 4-6, 4-21, 4-22,
4-24, 6-35, 6-37
See also lines
ABM 4-18
clearing 3-14
commands 1-15
data transfer state 6-16
definition of 1-4
errors 2-5, 6-39
establishment 4-21, 5-5
idle 3-14
multipoint 1-6, 1-14, 4-18, 5-5
point-to-point 1-6, 1-14
shut down 4-12, 4-22
unconditional 4-22
Index–15
Index
links (continued)
shutting down 4-1
start up 4-12
starting 4-1, 5-2, 5-3
X.21 3-13, 5-2, 5-5
leased lines 3-15
LIU 1-1, 1-2, 1-3, 2-1, 2-5, 2-17, 5-2, 6-2, 6-9, 6-40
buffer space 2-16
X.21 3-1
logical disconnect 1-15
Logically Disconnected State (LDS) 2-7, 2-8
low-order bit
control field 1-11
M
masters 1-18
maximum frame-size parameter
See procedure calls
memory allocation 2-18
memory requirements 2-17
messages
asynchronous 4-12, 4-19, 5-2
response 5-6
mode
DISC 5-5
setting 4-20
MODE SET request 2-8
mode-setting 2-8
sequence 2-10
mode-setting commands 4-20
See commands
SIM 4-20
mode-setting frames 2-8, 2-10
mode-setting sequence 2-10, 4-21
modems 2-5, 6-16
connection 2-6, 4-19, 6-31
disconnect 4-22, 6-31
establishment 4-19
Index–16
Index
modems (continued)
control 2-3, 3-3
DSR 4-19, 6-16, 6-31
DTR 2-5, 4-19, 4-22, 6-16, 6-31
functions 4-12
requests 2-10
errors 4-24
failures 2-8
full-duplex 1-3
half-duplex 1-3
modem connection 4-19
MODEM CONTROL request 2-8
problems 4-23
X.21 3-8
modes
See stations
DEAD 2-8, 2-11, 4-22, 6-29, 6-30
DISC 2-8, 4-22, 6-29
SIM 6-29
MODESETTING
See states
MODESETTING state 2-8
multiple
OPEN calls 4-12
openers 4-1
multipoint links
See links
N
Netinfo sequence 5-4, 6-46
networks 6-46
no-wait depth 4-6, 4-21
NonStop System 2-6
Nr parameter 1-13, 1-14, 1-15, 1-16
Nr values 1-14
NRM
Ns parameter 1-13, 1-14, 1-15, 1-16
Index–17
Index
O
operation completion 4-7
operations
completion 4-9
operations I/O 4-9
options
OPTIONA field 2-16
Option_One 2-14
Option_Two 2-15/16
output frames
See frames
output queue 3-14
P
packets 3-1
parameters
procedure calls
See procedure calls
peers 1-18
physical I/O 3-3
point-to-point links
See links
poll bit 2-11
poll cycle 2-14
poll/final bit 1-13, 4-21, 4-26, 6-26
polling 1-6, 1-9, 1-15, 1-16, 2-6, 2-12, 2-13, 4-21, 4-22, 6-37
alternate 2-12, 2-14
intervals 2-12
Option_One 2-14
order 2-13
RNR frames 2-13
standard 2-12
Station List 2-14
polling order 2-14
primary process 4-6
primary stations
See stations
Index–18
Index
procedure calls 4-1
ABEND 4-2, 4-10
AWAITIO 4-2, 4-9, 4-10, 4-12, 4-23
filenum parameter 4-10
CANCEL 4-25
CLOSE 4-12, 4-22, 5-6
DEVICEINFO 4-2, 4-4
device-type parameter 4-4
file-name parameter 4-4
maximum-frame-size parameter 4-4
FILEINFO 4-2, 4-7, 4-12, 4-23
error parameter 4-7
NUMOUT 4-2
width parameter 4-8
OPEN 1-1, 4-2, 4-5, 4-13, 4-16, 4-19, 4-22, 5-1, 5-6, 6-2
file-name parameter 4-5
flags parameter 4-5/6
sync-depth parameter
opening line 4-2
READ 1-1, 4-9, 4-12, 4-19, 4-23, 5-2
SETMODE 4-2, 4-11, 4-12, 4-19, 4-26
function parameter 4-11
parameter-1 parameter 4-11
WRITE 1-1, 4-2, 4-9
buffer parameter 4-9
write-count parameter 4-9
WRITEREAD 3-5, 4-9, 4-13, 4-15, 4-17, 4-18, 4-19, 4-20, 4-21, 4-22, 4-23,
4-26, 5-2, 5-3, 5-5, 5-6
buffer parameter 4-15, 4-19, 4-25
count-read parameter 4-16
read-count parameter 4-16
tag parameter 4-16
write-count parameter 4-15
process
delete 4-10
primary 4-6
process ID 4-10
Index–19
Index
process pairs 4-10
processes
backup 4-6
multiple 4-12
outstanding requests 6-25
protocol 4-23
error 2-8
management 3-2
task 3-2, 3-3
Protocol Manager 2-1, 2-3, 3-2
protocol model
ADCCP/X21 5-3
protocol module 1-11, 4-13, 4-18, 4-20, 5-2
line-configuration options 6-9
protocol task 4-12, 4-23
protocols
See also Level 1 and Level 2 Protocols
ADCCP 5-5
Q
quality reports
See lines
queuing
frames 2-6
R
RD response
See response codes
read requests 4-6
reads
flushing 6-25, 6-26
outstanding 6-25
flush 4-25
READYÎDLE state 2-4, 2-6
See command codes
Receive Ready (RR) code
See command codes
Reject (REJ)
See command codes
release procedures 3-3
Index–20
Index
remote stations 2-8
request 6-43
DEFINELIST 6-34
RECEIVETEXT 6-25, 6-26/28
SET X.21 CONFIGURATION 6-40
TRACE BLOCK 6-20
Request Disconnect (RD) response
See response codes
Request Initialization Mode (RIM) response
See response codes
requests 1-1/2, 2-1, 2-3, 2-10, 2-11, 2-14, 4-1, 4-6, 4-12, 4-23, 5-2, 6-1
aborting 6-18
active 5-3
application 1-10, 2-1, 2-3, 2-4, 2-6
buffer format 4-25
See also WRITEREAD
cancel 6-26
cancellation 4-24, 4-25, 5-3
CHANGELIST 1-2, 2-6, 2-10, 2-14, 4-18, 4-25, 6-29, 6-35/36
CONFIGURATION 4-14
CONNECT 3-6, 3-7, 3-10, 3-13, 5-3, 5-4, 5-5, 6-19, 6-44/48
passive 6-44
DEFINELIST 1-2, 1-10, 2-6, 2-10, 2-18, 4-17, 4-18, 4-25, 6-1, 6-32, 6-37
DISCONNECT 3-10, 3-14, 3-15, 5-3, 5-5, 5-6, 6-19, 6-49/50
disconnect 2-5
FETCH CONFIGURATION 1-2, 4-27, 5-2, 6-2, 6-9
response-buffer format 6-9/10
FETCH STATISTICS 1-2, 6-13, 6-18
response buffer format 6-13/15
FETCH X.21 CONFIGURATION 5-2, 6-40/42, 6-43
format
fields 4-26
Function field 4-26
Modifier field 4-26
Request ID field 4-26
Text field 4-26
Text In field 4-26
Text Out field 4-26
function codes 6-1
ID 4-19, 4-21
LINE QUALITY 6-13, 6-39
MODE SET 1-2, 2-6, 2-8, 2-11, 3-10, 4-19, 4-20, 4-25, 5-5, 6-19, 6-29
Index–21
Index
requests (continued)
MODEM CONTROL 1-2, 2-5, 2-8, 2-10, 4-19, 4-22, 6-16, 6-31
MODESET 4-22
no-wait 4-21
passive 5-3
RECEIVETEXT 1-2, 2-6, 2-12, 2-13, 3-10, 4-19, 4-20, 4-21, 4-25, 5-5,
6-19, 6-29
aborted 6-25
redundant 4-24
retry 4-12
SCAN LIST 1-2, 2-6, 2-14, 4-18, 6-37/38
SENDTEXT 1-2, 2-6, 2-10, 2-12, 2-13, 2-18, 3-10, 4-21, 4-26, 5-5, 6-19,
6-23/24
SET CONFIGURATION 1-2, 1-10, 2-16, 2-17, 4-13, 4-16, 4-26, 5-2, 6-2,
6-18, 6-37
buffer format 6-2/3
SET X.21 CONFIGURATION 3-3, 3-4, 3-5, 3-10, 5-2, 5-4
START 2-5, 4-19
START OPERATION 1-2, 3-4, 3-7, 3-15, 4-22, 5-2, 5-4, 5-5, 6-16/17,
6-18
ADCCP 6-16
X.21 6-16/17
START TRACE 6-11, 6-18
status 4-21
STOP 2-5
STOP OPERATION 1-2, 3-10, 4-22, 4-25, 5-5, 6-18/19, 6-49
ADCCP 6-18
X.21 6-19
STOP TRACE 6-12, 6-18
TRANSLATE TABLE 1-2, 1-17
Reset (RSET) command
See command codes
resources
utilization 1-18
response buffer 4-19, 4-21
response codes 1-15
DM 1-15
RD 1-15
RIM 1-15
UA 1-15, 1-16
Index–22
Index
response frames
See frames
responses 1-1, 2-3, 2-6, 3-7, 4-21, 4-23, 5-2, 6-1
See also requests
asynchronous
format 4-27
asynchronous messages
format 4-27
Reserved field 4-27
Response field 4-27
Status field 4-27
Text field 4-27
Text In field 4-27
buffer format 4-25
See also WRITEREAD
DM 4-22
format
Reserved field 4-26
Response field 4-26
Status field 4-26
Text field 4-27
Text In field 4-27
LINE QUALITY 4-27
RIM 4-20
Status 100 3-6
TRANSLATE TABLE 1-17
UA 4-20
retries 2-6, 6-39
L2RETRY 2-10
RIM response
See response codes
RNR 1-15
RR 1-15
RS-232
See interfaces
RS-232 interface 3-3
RS-449
See interfaces
RSET command
See command codes
Index–23
Index
S
SABM command
See command codes
SABME command
See command codes
SARME command
See command codes ,
scan list 6-38
station ID 2-14
SCAN LIST request 2-6
secondary stations
See stations
selection signal 3-12, 6-45
See command codes
Set Asynchronous Response Mode (SARM) command
See command codes
Set Asynchronous Response Mode Extended (SARME) command
See command codes
Set Initialization Mode (SIM) command
See command codes
Set Normal Response Mode (SABM) command
See command codes
Set Normal Response Mode (SNRM) command
See command codes
Set Normal Response Mode Extended (SABME) command
See command codes
Set Normal Response Mode Extended (SNRME) command
See command codes
shut down
reversal 4-22
signals
See also modem control
See also X.21
call progress 5-3
levels 6-13
selection sequence 5-3, 5-4
selection signal sequence
syntactic guidelines 5-3
Index–24
Index
SIM command
See command codes
sizing 2-16
slaves 1-18
SNRM command
See command codes
SNRME command
See command codes
software
levels of 2-1, 2-3
SREJ 1-15
state machines 2-6, 2-7
states 2-1, 2-4, 2-10
ADCCP/X21 interface
call establishment 3-9
clearing 3-9
connected 3-9
quiescent 3-9, 3-10
stopped 3-9, 3-10
call establishment 3-10, 3-12
change 2-6, 2-11
changes 2-10
connected 3-13, 5-4
data transfer 3-15
DISCÎDLE 2-4, 2-5, 2-6
DISC^WAIT 2-4, 2-5, 2-6
DTE 3-12
frame transfer 3-14
idle 3-13
IS 2-7, 2-8, 2-10
ITS 2-8, 2-10, 2-13
LDS 2-7, 2-8
lines 3-15
links 3-15
X.21 circuit-switched lines 3-9
MODESETTING 2-7, 2-8, 2-10
quiescent 3-12, 3-15, 5-2
READYÎDLE 2-4, 2-6
transfer 3-15
transitions 2-5
transmit 3-13
Index–25
Index
states (continued)
X.21
data transfer 5-2
quiescent 6-17
quiescent ready 6-17
XMIT 2-4, 2-6
Station List 2-14, 2-17, 6-32, 6-34
station ID
multipoint lines 2-14
point-to-point lines 2-14
Station Manager 2-1, 3-2
See also Level 1 protocol
station states
IS 2-7
stations 1-8, 1-11, 1-14, 1-15, 1-17, 2-1, 2-3, 2-6, 2-8, 2-12, 2-16, 2-17, 2-18,
4-6, 4-18, 4-21, 5-3, 6-30, 6-35
ADCCP 5-4
addresses 1-9, 4-18, 6-32
busy 1-11, 2-12
called 3-1
calling 3-1
combined 1-4, 1-9, 2-10, 4-1, 4-20, 4-21, 6-29
conditions 2-10, 2-12, 2-14, 4-18, 6-33, 6-35
clearing 2-11
dead 2-11
DRNR 2-10
ERRORSTOP 2-10, 2-13
FRMROUT 2-11
LRNR 2-11, 2-13
NOPOLL 2-11, 2-13, 2-14
RNR 2-14, 2-18
SREJOUT 2-11
definitions 1-4. 4-18
disabled 2-18. 6-35
disconnecting 2-10,4-24. 6-29
failure 2-10
ID 1-10, 4-18, 4-21, 4-26, 6-32, 6-37
inactive 6-35
initialization 4-20
list 4-12, 4-17, 4-20, 5-5
local 2-7, 2-10, 2-11, 2-12, 2-13, 2-14, 4-20, 4-22, 6-29, 6-32, 6-37
malfunctioning 2-6
Index–26
Index
stations (continued)
malfunctions 4-24
management 3-2
modes 4-12, 5-5
DEAD 4-20
modes
polling 2-6
polling of 2-13
polling order 6-37
primary 1-2, 1-4, 1-6, 1-9, 1-13, 1-15, 1-16, 2-6, 2-8, 2-10, 2-13, 2-14,
2-15, 4-1, 4-20, 4-22, 6-29, 6-32
address 2-14
logically disconnected 1-15
receiving 1-15
remote 2-1, 2-3, 2-6, 2-7, 2-8, 2-10, 2-11, 2-12, 2-13, 2-16, 3-10, 3-12,
3-13, 4-12, 4-20, 4-21, 4-22, 4-24, 5-1, 5-3, 5-5, 6-23, 6-24, 6-32
address 2-14
secondary 1-2, 1-4, 1-6, 1-9, 1-13, 1-14, 1-15, 1-16, 2-8, 2-10, 2-11, 2-12,
2-14, 2-15, 4-1, 4-20, 4-22, 6-25, 6-29, 6-37
address 2-14
groups of 2-6
shut down 4-22
starting condition 6-32
state 6-32
state modifier 6-32
states 4-12
IS 2-8, 2-10
ITS 2-8, 2-10, 2-11, 2-13
LDS 2-7, 2-8, 2-10, 2-11
MODESETTING 2-7, 2-8, 2-10
supervisor 1-6
suspension 2-18
tributary 1-6
typed 1-4, 2-14, 4-18
status byte 4-26, 6-26/28
See also condition codes
status code 5-6
status field 6-30
status message 4-23
Index–27
Index
substations
combined 2-11
primary 2-11
secondary 2-11
supervisor
See stations
switched lines
See lines
synchronization timing 1-9
SYSGEN 1-9, 1-10, 2-17, 3-3, 4-24, 5-2, 6-2
See also SYSGEN parameters
configuration file 4-13
line options 6-3
parameters
AFLDn 6-32
AUTOCLOSE 4-24
AUTOCONF 4-13, 4-24, 6-2
AUTOLOAD 4-24
NOAUTOSTOP 4-24
THRESHOLD 6-39
SYSGEN parameters
AUTOCONF 4-13, 5-2
FLAGIDLE 1-9
IDLETIMER 2-12
L2RETRY 2-15, 6-39
POLL 2-12
STATIONS 2-17
T1TIMER 2-11, 2-15
WINDOW 2-17, 2-18
T
T1TIMER
See timers
tasks 4-1
6100 ADCCP 5-5
ADCCP 5-5
ADCCP/X.21 5-5
asynchronous messages 4-1
closing lines 4-1
defining station list 4-1
Index–28
Index
tasks (continued)
modem connection 4-19
See also modems
opening lines 4-1, 4-2
protocol 4-12
setting line parameters 4-1
shutting down link 4-1
starting link 4-1
transferring data 4-1
X.21 5-1
TEST command
See command codes
time intervals 3-6
time limits 3-6/7, 6-49
timeouts 2-10, 4-9
timers 3-14
IDLETIMER 2-12, 2-13
T1TIMER 2-6, 2-11, 2-15
trace block 2-17
trace buffers 2-17
traces 1-3, 2-16, 2-18
traffic 2-16, 2-17, 2-18
transitions
leased lines 3-15
translation
ASCII to EBCDIC 1-3
EBCDIC to ASCII 1-3
translation tables 1-17
ttransmissions 2-3, 2-6, 2-16
control 2-13
retry 2-6
TWA (two-way alternate) 2-12, 4-21
tributary
See stations
tuning 1-18, 2-16
TWA
See transmissions
two-way alternate (TWA) 4-21
Index–29
Index
U
UA response
See response codes ,
UI frame
See also ADCCP commands
Unnumbered Acknowledgment (UA) response
See response codes
Unnumbered Information (UI) frame
See also ADCCP commands
user data 3-1, 3-8
USER0 frame
See frames
USER1 frame
See frames
USER3 frame
See frames
V
V.35
See interfaces
W
window size 4-6, 4-21
windows 2-17
size 2-18
write requests 4-6
See also procedure calls
See also requests
WRITEREAD 3-3, 3-10
WRITEREAD calls 1-1
X
X.21
abbreviated address 5-3
address 5-3
application tasks 5-1
call charges 5-3
call establishment 5-3, 5-6
call identification 5-4
call progress signals 5-3
Index–30
Index
X.21 (continued)
call redirection 5-3
called line address 5-4
calls
clearing 6-49
direct 6-45, 6-44
establishment 6-45
incoming 6-44
outgoing 6-44, 6-45
progress signal 6-46
request 6-45
selective direct 6-44, 6-46
charging information 5-4, 5-6
circuit-switched parameter 5-2
clearing connections 5-6
clearing phase 3-3
configuration block 3-4, 6-40, 6-42/43
configuration parameters 6-42
connection 3-2
disconnect
active 6-49
passive 6-49
driver 3-3, 6-17
establishing connections 5-4
facility
cancellation 5-3, 6-44, 6-46, 6-47
registration 5-3, 6-44, 6-46, 6-47
facility request block 5-4
facility request codes 5-3
facility request signal 5-4
full address 5-3
interface 3-3
circuits 3-8
network 3-1, 3-8
network charges 6-49
optional facility 5-3
outgoing calls 5-3
progress signals 5-4, 6-47
releasing connections 5-4
selection signal sequence 5-4
address 6-45
syntactic guidelines 5-3
Index–31
Index
X.21 (continued)
special facilities 5-3
time limits 3-6/7
X.21 Call request
Direct Call 3-12
Normal Call 3-12
Selective Direct Call 3-12
XID command
See command codes
XMIT state 2-4, 2-6
Z
zero bit insertion 1-17
Index–32

6100 ADCCP Programming Manual

Transkript

Podobné dokumenty

www.sas-trinec.cz

operating weights - Agrotechnic Moravia

Blade mCX Tandem Rescue Manual

ISO/IEC 13239

Sametime