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.
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.
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.
New and Changed Information iv 069225 Tandem Computers Incorporated
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
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.
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 Pr
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.
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.
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
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.
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.
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.
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.
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.
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.
Introduction to 6100 ADCCP Features of the 6100 ADCCP Product 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.
Introduction to 6100 ADCCP Features of the 6100 ADCCP Product 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 li
Introduction to 6100 ADCCP 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.
Introduction to 6100 ADCCP 6100 ADCCP Concepts and Context Figure 1-1.
Introduction to 6100 ADCCP 6100 ADCCP Concepts and Context 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.
Introduction to 6100 ADCCP 6100 ADCCP Concepts and Context Asynchronous Response Mode (ARM) 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.
Introduction to 6100 ADCCP 6100 ADCCP Concepts and Context 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.
Introduction to 6100 ADCCP 6100 ADCCP Concepts and Context 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.
Introduction to 6100 ADCCP 6100 ADCCP Concepts and Context 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.
Introduction to 6100 ADCCP 6100 ADCCP Concepts and Context 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.
Introduction to 6100 ADCCP 6100 ADCCP Concepts and Context 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.
Introduction to 6100 ADCCP 6100 ADCCP Concepts and Context 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).
Introduction to 6100 ADCCP 6100 ADCCP Concepts and Context 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.
Introduction to 6100 ADCCP 6100 ADCCP Concepts and Context 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.
Introduction to 6100 ADCCP 6100 ADCCP Concepts and Context 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.
Introduction to 6100 ADCCP 6100 ADCCP Concepts and Context 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.
Introduction to 6100 ADCCP 6100 ADCCP Concepts and Context 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.
Introduction to 6100 ADCCP 6100 ADCCP Concepts and Context Table 1-2.
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.
ADCCP Link and Station Management Protocol Task Architecture 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.
ADCCP Link and Station Management Protocol Task Architecture 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).
ADCCP Link and Station Management Link States and Transitions 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.
ADCCP Link and Station Management Link States and Transitions Figure 2-3. Link States and Transitions Line Downloaded DISC^IDLE ADCCP Asserts DTR DSR Timeout Disconnect Request or Modem Error DISC^WAIT Modem Asserts DSR READY^IDLE Receives Data Frame Queued for Output Frame Sent XMIT 009 DISC^IDLE State The DISC^IDLE state occurs after the LIU has been downloaded and started with CMI, but before ADCCP has asserted a DTR signal to the modem.
ADCCP Link and Station Management Station States and Transitions READY^IDLE State In the READY^IDLE 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^IDLE state, the state changes to DISC^IDLE. If an application makes a request to send data to a specific station, the state changes to the XMIT state.
ADCCP Link and Station Management Station States and Transitions 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.
ADCCP Link and Station Management Station States and Transitions 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).
ADCCP Link and Station Management Station States and Transitions 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.
ADCCP Link and Station Management Station States and Transitions 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.
ADCCP Link and Station Management Station States and Transitions 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.
ADCCP Link and Station Management 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.
ADCCP Link and Station Management 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.
ADCCP Link and Station Management 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.
ADCCP Link and Station Management 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.
ADCCP Link and Station Management Station and Data Capacity on Links 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.
ADCCP Link and Station Management Station and Data Capacity on Links The SYSGEN MAXFRAME parameter determines the size of each input and output buffer.
ADCCP Link and Station Management Station and Data Capacity on Links 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.
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.
ADCCP/X21 Protocol Module 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.
ADCCP/X21 Protocol Module Line Configuration Options 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.
ADCCP/X21 Protocol Module Line Configuration Options 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.
ADCCP/X21 Protocol Module Line Configuration Options 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.
ADCCP/X21 Protocol Module Line Configuration Options 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.
ADCCP/X21 Protocol Module Line Configuration Options 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.
ADCCP/X21 Protocol Module Link States and Transitions 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.
ADCCP/X21 Protocol Module Link States and Transitions 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.
ADCCP/X21 Protocol Module Link States and Transitions 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.
ADCCP/X21 Protocol Module Link States and Transitions Figure 3-4. X.
ADCCP/X21 Protocol Module Link States and Transitions 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.
ADCCP/X21 Protocol Module Link States and Transitions 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.
ADCCP/X21 Protocol Module Link States and Transitions 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/X21 Protocol Module Link States and Transitions 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.
ADCCP/X21 Protocol Module Link States and Transitions Figure 3-6.
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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP Application Tasks This example shows how a line could be opened using the C programming language.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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].
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP Application Tasks dPtr->text_out = textout; dPtr->text_in = textin; count = length; c_code = WRITEREAD(rfnum,(short *)dPtr,length,count,&count_trans); if (c_code != CCE) { FILEINFO(rfnum,&error); printf("Error %d occurred on WRITEREAD\n",error); ABEND(); } } For an ABM link, the request provides the address of the local primary substation.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP 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.
Writing Applications that Use ADCCP Format of Requests and Responses 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 ).
Writing Applications that Use ADCCP Format of Requests and Responses Definitions of Fields in 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.
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.
Writing Applications that Use ADCCP/X21 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.
Writing Applications that Use ADCCP/X21 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.
Writing Applications that Use ADCCP/X21 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.
Writing Applications that Use ADCCP/X21 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.
Writing Applications that Use ADCCP/X21 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.
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.
Requests and Responses (1) SET CONFIGURATION (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.
Requests and Responses (1) SET CONFIGURATION 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 .
Requests and Responses (1) SET CONFIGURATION Table 6-2.
Requests and Responses (1) SET CONFIGURATION Table 6-2. Descriptions of SET CONFIGURATION Parameters (Page 2 of 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.
Requests and Responses (1) SET CONFIGURATION Table 6-2. Descriptions of SET CONFIGURATION Parameters (Page 3 of 4) 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.
Requests and Responses (1) SET CONFIGURATION 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.
Requests and Responses (1) SET CONFIGURATION 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.
Requests and Responses (2) FETCH CONFIGURATION (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.
Requests and Responses (2) FETCH CONFIGURATION 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 069225 Tandem Computers Incorporated :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
Requests and Responses (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.
Requests and Responses (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.
Requests and Responses (5) FETCH STATISTICS (5) FETCH STATISTICS 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.
Requests and Responses (5) FETCH STATISTICS 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.
Requests and Responses (5) FETCH STATISTICS 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.
Requests and Responses (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.
Requests and Responses (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 := A unique value from 1 to 32767, determined by the application 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.
Requests and Responses (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.
Requests and Responses (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.
Requests and Responses (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.
Requests and Responses (64) TRANSLATE TABLE (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.
Requests and Responses (64) TRANSLATE TABLE 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. For a list of the status codes and their definitions, see “Status Code Definitions” at the end of this section.
Requests and Responses (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.
Requests and Responses (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.
Requests and Responses (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.
Requests and Responses (66) RECEIVETEXT Response Request ID := A unique value from 1 through 32767, 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.
Requests and Responses (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.
Requests and Responses (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.
Requests and Responses (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.
Requests and Responses (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.
Requests and Responses (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.
Requests and Responses (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.
Requests and Responses (69) DEFINELIST The request buffer format is: 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 := A unique value from 1 to 32767, determined by the application. Text Out := Number of stations multiplied by (AFLDn + 3).
Requests and Responses (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.
Requests and Responses (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.
Requests and Responses (70) CHANGELIST The response buffer format is: 6–36 Response := 70 Status := 0 if all changes were made, otherwise a code for the error that occurred Request ID := The same as in the request Text Out := 0 Text In := 0 Text None 069225 Tandem Computers Incorporated
Requests and Responses (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.
Requests and Responses (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. For a list of the status codes and their definitions, see “Status Code Definitions” at the end of this section.
Requests and Responses (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.
Requests and Responses (80) SET X.21 CONFIGURATION (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.
Requests and Responses (80) SET X.21 CONFIGURATION 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. 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: Response := 80 Status := 0 if the changes have taken place, otherwise a code for the error that occurred.
Requests and Responses (81) FETCH X.21 CONFIGURATION (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”.
Requests and Responses (81) FETCH X.21 CONFIGURATION 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 := The same as in the request Text Out := 0 Text In := 1 if error detail is supplied, 0 if not.
Requests and Responses (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.
Requests and Responses (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.
Requests and Responses (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.
Requests and Responses (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.
Requests and Responses (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.
Requests and Responses (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.
Requests and Responses (83) DISCONNECT Response The DISCONNECT response is the expected answer to the DISCONNECT request. For a list of the status codes and their definitions, see “Status Code Definitions” at the end of this section.
Requests and Responses Status Code Definitions 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.
Requests and Responses Status Code Definitions 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.
Requests and Responses Status Code Definitions 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.
Requests and Responses Status Code Definitions 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.
Requests and Responses Status Code Definitions 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.
Requests and Responses Status Code Definitions 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.
Requests and Responses Status Code Definitions 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.
Requests and Responses Status Code Definitions 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.
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.
File-System Error Codes 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.
File-System Error Codes 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.
File-System Error Codes File-System Error Codes 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.
File-System Error Codes File-System Error Codes Table A-1. File-System Error Codes– Do Not Retry (Page 2 of 2) Error Code 24 60 61 66 99 100 201 1160 Description/Solution 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.
File-System Error Codes File-System Error Codes 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 Description/Solution 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.
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.
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.
ADCCP Programming Example Using Transaction Application Language (TAL) 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.
ADCCP Programming Example Using Transaction Application Language (TAL) This format is for a command or response buffer without a Text field. STRUCT CONFIG = MSG; BEGIN STRING CMD; STRING MOD; INT REQ^ID; INT TEXT^OUT; INT TEXT^IN; This format is for a command/response buffer for the SET CONFIGURATION or FETCH CONFIGURATION request.
ADCCP Programming Example Using Transaction Application Language (TAL) 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.
ADCCP Programming Example Using Transaction Application Language (TAL) Here, the default parameters defined as literals near the beginning of the listing are grouped in an array.
ADCCP Programming Example Using Transaction Application Language (TAL) 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 .
ADCCP Programming Example Using Transaction Application Language (TAL) 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.
ADCCP Programming Example Using Transaction Application Language (TAL) 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).
ADCCP Programming Example Using Transaction Application Language (TAL) 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^o(filename,filenum,waitio,sync); int .filename, .
ADCCP Programming Example Using Transaction Application Language (TAL) ?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.
ADCCP Programming Example Using Transaction Application Language (TAL) 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^EVENT" 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.
ADCCP Programming Example Using Transaction Application Language (TAL) CALL READUPDATE(RECFILE,RECBUFF,rec^io^size);!post another readupdate if <> then begin CALL FILEINFO(recfile,ERROR); sbuf ':=' "$RECEIVE readupdate error: " -> @ptr; call numout(sbuf[@ptr '-' @sbuf],error,10,5); call write(outfile,outbuf,@ptr '-' @sbuf); if <> then call abend^; call awaitio(outfile); end; if last^pid = [0,0,0] then return true; !signal system msg return false; !signal process msg end; ?page ! !<<< main of next^event >>>
ADCCP Programming Example Using Transaction Application Language (TAL) If the file number is asynfnum, an asynchronous read completed. The program prints the asynchronous message on the home terminal.
ADCCP Programming Example Using Transaction Application Language (TAL) 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); call numout(ptr,error,10,3); ptr[3] ':=' " on 1st open." -> @ptr; call write(outfile,outbuf,@ptr '-' @sbuf); call awaitio(outfile); call abend^; end; The third OPEN, wfnum, will be used for SENDTEXT requests. call open(startup^msg.
ADCCP Programming Example Using Transaction Application Language (TAL) 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.
ADCCP Programming Example Using Transaction Application Language (TAL) ! ! !<<< 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); if <> then call abend^; startup^msg.params[count^read-41] := 0; Open the home terminal (or other output file). call open(startup^msg.
ADCCP Programming Example Using Transaction Application Language (TAL) 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^o := 400; !preset default to 4 seconds scan ptr until " " -> @ptr; scan ptr while " " -> @ptr; if not $carry then call numin(ptr,t^o,10,status); if status then begin sbuf ':=' "Illegal TIMEOUT value.
ADCCP Programming Example Using Transaction Application Language (TAL) 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.
ADCCP Programming Example Using Transaction Application Language (TAL) ?page ! proc put^suppress^msg; begin string .
ADCCP Programming Example Using Transaction Application Language (TAL) ?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^awaitio(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)
ADCCP Programming Example Using Transaction Application Language (TAL) return error; end; !end of check^awaitio 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; !optional value parameter string .list; !optional reference parameter begin int length; d.msg.
ADCCP Programming Example Using Transaction Application Language (TAL) 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; SET CONFIGURATION request. CALL RECEIVE(RFNUM,B^SET^CONFIG,40,0,LTF^SET^CONFIG,$LEN(D.
ADCCP Programming Example Using Transaction Application Language (TAL) ?PAGE "MAIN PROCEDURE" PROC main^ MAIN; BEGIN subproc some^more^init; 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]; write^posted := false; end; end; This procedure cancels any dangling I/O requests.
ADCCP Programming Example Using Transaction Application Language (TAL) 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^IO^PIPES sucked up a read.
ADCCP Programming Example Using Transaction Application Language (TAL) CHANGELIST request. call check^awaitio(wait^time,ltf^changelist); if error then begin sbuf[9] ':=' "changelist error : " -> @ptr; call write^err^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.
ADCCP Programming Example Using Transaction Application Language (TAL) if (out^key := out^key + 1) = 32767 then out^key := 0; end; This procedure posts RECEIVETEXT and SENDTEXT requests. subproc post^ios; 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.
ADCCP Programming Example Using Transaction Application Language (TAL) 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^in after a RECEIVETEXT completes. subproc frame^in; begin int length^left,IPTR; The tag is compared to the expected value.
ADCCP Programming Example Using Transaction Application Language (TAL) 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.
ADCCP Programming Example Using Transaction Application Language (TAL) The main procedure calls frame^out 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^out; 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^OK and D.COMMAND^RESPONSE.
ADCCP Programming Example Using Transaction Application Language (TAL) 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^out; begin sbuf[9] ':=' "Timeout." -> @ptr; call write^err^msg; end; ?page subproc see^if^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].
ADCCP Programming Example Using Transaction Application Language (TAL) Establish the session.
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.
ADCCP Programming Example Using C 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(
ADCCP Programming Example Using C { 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 NOCA
ADCCP Programming Example Using C 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.
ADCCP Programming Example Using C 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.
ADCCP Programming Example Using C short count; short count_trans; int error; /* * The values for the specific request are assigned to the * structure for the request and the buffer length is set.
ADCCP Programming Example Using C printf("Status code %d.\n",code); printf("There is no room for the request frame on the LIU.\n"); break; case 5: printf("Status code %d.\n",code); printf("Addressing error (invalid task ID) occurred in the controller."); break; case 6: printf("Status code %d.\n",code); printf("A resource shortage occurred in the controller."); break; case 8: printf("Status code %d.\n",code); printf("Too many of these requests are already queued.\n"); break; case 9: printf("Status code %d.
ADCCP Programming Example Using C case 28: printf("Status code %d.\n",code); 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("Status code %d.\n",code); printf("A new request replaced the one in progress.\n"); break; case 30: printf("Status code %d.\n",code); printf("RNR condition lasted too long.\n"); break; case 31: printf("Status code %d.
ADCCP Programming Example Using C printf("Status code %d.\n",code); printf("Specified Poll Cycles done.\n"); break; case 64: printf("Status code %d.\n",code); printf("UI frame received.\m"); break; case 65: printf("Status code %d.\n",code); printf("RIM-Primary, SIM-secondary.\n"); break; case 66: printf("Status code %d.\n",code); printf("USER0 frame received.\n"); break; case 67: printf("Status code %d.\n",code); printf("DM-primary, SARM-secondary.\n"); break; case 68: printf("Status code %d.
ADCCP Programming Example Using C break; case 81: printf("Status code %d.\n",code); printf("FRMR-Primary, RSPR-Secondary.\n"); break; case 82: printf("Status code %d.\n",code); printf("USER2 frame received.\n"); break; case 83: printf("Status code %d.\n",code); printf("RSET frame received, secondary.\n"); break; case 84: printf("Status code %d.\n",code); printf("Invalid frame received.\n"); break; case 85: printf("Status code %d.\n",code); printf("Invalid frame received.
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 Code Conversion Table D-1.
ASCII to EBCDIC Code Conversion Table D-1.
ASCII to EBCDIC Code Conversion Table D-1.
ASCII to EBCDIC Code Conversion Table D-1.
ASCII to EBCDIC Code Conversion Table D-1.
ASCII to EBCDIC Code Conversion Table D-1.
ASCII to EBCDIC Code Conversion Table D-1.
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.
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.
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).
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.
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.
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.
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.
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,
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.
Index Asynchronous Response Mode (ARM) See line control modes 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.
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.
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 See also command codes 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
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.
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.
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^IDLE 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.
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 See line control modes F facilities special 6-46 facility See also X.
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
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
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-fram
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.
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^IDLE 2-6 DISC^WAIT 2-5, 2-6 READY^IDLE 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 configur
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^IDLE 2-4, 2-5 DISC^WAIT 2-4 READY^IDLE 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.
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.
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.
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-
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 filenum 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 filenum parameter 4-5 flags parameter 4-5/6 sync-depth parameter opening line 4-2 READ 1-
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 R
Index remote stations 2-8 request 6-43 DEFINELIST 6-34 RECEIVETEXT 6-25, 6-26/28 SET X.
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.
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 Request ID field 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 Request ID field 4-26 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
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 Selective Reject (SREJ) 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
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^IDLE 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-
Index states (continued) X.
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,
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 S
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.
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.
Index X.
Index X.21 (continued) special facilities 5-3 time limits 3-6/7 X.
