Envoy Application Programming Manual Abstract The Envoy subsystem provides general-purpose protocol support that enables application programs or terminals to communicate over communications lines on a ServerNet wide area network (SWAN) concentrator. This manual describes Envoy application programming, management functions, and the implementation of protocols used with Envoy. Product Version Envoy F40 Supported Releases This manual supports G03.
Document History Part Number Product Version Published 427159-001 NA November 2000 Ordering Information For manual ordering information: domestic U.S. customers, call 1-800-243-6886; international customers, contact your local sales representative. Document Disclaimer Information contained in a manual is subject to change without notice. Please check with your authorized representative to make sure you have the most recent information.
Envoy Application Programming Manual Glossary Index Examples Figures What’s New in This Manual xxiii Manual Information xxiii New and Changed Information xxiii About This Manual xxv xxv Who Should Use This Manual How This Manual Is Organized xxv Related Documents and Online Tools xxvii Your Comments Invited xxxi Notation Conventions xxxii 1.
2. Software Concepts Contents 2.
3. BISYNC Point-To-Point Protocol (continued) Contents 3.
4. BISYNC Centralized Multipoint Supervisor Protocol Contents 4.
4. BISYNC Centralized Multipoint Supervisor Protocol (continued) Contents 4. BISYNC Centralized Multipoint Supervisor Protocol (continued) CONTROL Procedure (Send TTD) Line-Error Handling 4-35 4-36 Initial READ Operation 4-36 Continuation READ Operation Initial WRITE Operation 4-39 4-41 Continuation WRITE Operation 4-43 Programming Examples 4-44 5.
5. BISYNC Multipoint Tributary Protocol (continued) Contents 5. BISYNC Multipoint Tributary Protocol (continued) READ-Type Bit 5-25 WRITE Procedure 5-26 WRITEREAD Procedure (Conversational Exchange) CONTROL Procedure (Send EOT) 5-28 CONTROL Procedure (Send WACK) CONTROL Procedure (Send TTD) Line-Error Handling 5-27 5-29 5-29 5-29 Initial READ Operation 5-29 Continuation READ Operation Programming Examples 5-31 5-35 6.
7. ADM-2 Multipoint Supervisor Protocol (continued) Contents 7.
8. TINET Multipoint Supervisor Protocol (continued) Contents 8.
9. Burroughs Point-To-Point Protocol Contents 9. Burroughs Point-To-Point Protocol Protocol Capabilities 9-1 Application Process Interface 9-2 9-2 Opening a Line Line Contention 9-3 Retries 9-3 Timeouts 9-3 File-System Procedures Message Formats 9-5 9-6 Normal Text Headings 9-3 9-6 File-System Errors 9-7 9-8 Errors 162 and 171 Line Action by Procedure Call 9-9 READ Procedure 9-9 WRITE Procedure 9-12 CONTROL Procedure (Send EOT) 9-15 CONTROL Procedure (Enable RVI) 9-15 10.
10. Asynchronous Line Supervisor Protocol (continued) Contents 10.
C. File-System Procedures (continued) Contents C. File-System Procedures (continued) HALTPOLL OPEN C-21 C-22 READ[X] C-24 SETMODE C-26 SETMODENOWAIT WRITE[X] C-31 C-32 WRITEREAD[X] C-34 D. Statistics Messages E.
Examples (continued) Contents Examples (continued) Example 2-5. Address List for Supervisor Station A 2-16 Example 2-6. Address List for Tributary Stations B and C Example 2-7. Polling Example Example 2-8. Selection Example Example 2-9. Error Handling By Receiver 2-24 Example 3-1. Initial Read (Line in CONTROL State) 3-18 Example 3-2. Timeout on Initial Read Example 3-3. Continuation READ (Line in READ State) Example 3-4. Initial READ (Line in WRITE State) 3-21 Example 3-5.
Examples (continued) Contents Examples (continued) Example 4-4. Change a Line’s Polling Type from Continuous to Noncontinuous 4-16 Example 4-5. Specific Polling 4-17 Example 4-6. Disable Polling 4-20 Example 4-7. Initial READ (Line in CONTROL State) Example 4-8. Continuation READ (Line in READ State) Example 4-9. Initial READ (Line in WRITE State) 4-29 Example 4-10. Initial WRITE Example 4-11. Continuation WRITE (Line in WRITE State) 4-32 Example 4-12.
Examples (continued) Contents Examples (continued) Example 5-14. Selected Tributary Receives a Message 5-39 Example 5-15. Program Code for BISYNC Multipoint Tributary Example 6-1. Configuration of a NASDAQ Full-Duplex Line Example 6-2. WAN Manager STATUS SERVER Command Example 7-1. Address List Example 7-2. Build an Address List Example 7-3. Specify Continuous Polling Example 7-4. Change a Line’s Polling Type Example 7-5. Specific Polling 7-14 Example 7-6.
Examples (continued) Contents Examples (continued) Example 8-3. Continuous Polling 8-11 Example 8-4. Change a Line’s Polling Type Example 8-5. Specific Polling 8-14 Example 8-6. Selective Polling (Before Calling DEFINELIST) 8-16 Example 8-7. Selective Polling (After Calling DEFINELIST) 8-17 Example 8-8. Remove Terminals from the Nonresponding List Example 8-9. MCW in Count Read or Written Example 8-10. TINET Polling Procedure 8-22 Example 8-11. TINET Select Procedure Example 8-12.
Examples (continued) Contents Examples (continued) Example C-2. Use of the Tag Parameter C-3 Example C-3. Address List Example C-4. Code to Define an Address List Array C-16 C-17 Figures Figure i. NonStop™ Himalaya S-Series Configuration and Management Manual Set xxvii Figure ii. TSM Manuals and Online Help Figure 1-1. Communication Data Links Figure 1-2. Envoy Subsystem Architecture 1-3 Figure 1-3. Overview of DSM Architecture 1-4 Figure 1-4.
Figures (continued) Contents Figures (continued) Figure 4-7. BISYNC Multipoint Supervisor Continuation READ 4-39 Figure 4-8. BISYNC Multipoint Supervisor Initial WRITE 4-41 Figure 4-9. BISYNC Multipoint Supervisor Continuation WRITE 4-43 Figure 4-10. BISYNC Multipoint Supervisor Station Addresses 4-45 Figure 4-11. BISYNC Multipoint Supervisor READ-WRITE Operation Figure 5-1. BISYNC Multipoint Tributary Polling Figure 5-2. BISYNC Multipoint Tributary Selection 5-6 Figure 5-3.
Figures (continued) Contents Figures (continued) Figure 10-2. Asynchronous Line Supervisor Selection 10-6 Figure 10-3. Asynchronous Line Supervisor READ Operation 10-21 Figure 10-4. Asynchronous Line Supervisor WRITE Operation 10-22 Tables Table 1-1. Protocols, Line Configurations, and Concentrator Types 1-8 Table 1-2. Programmatic Commands and Interactive (SCF) Commands 1-10 Table 2-1. Protocols, Line Configurations, and Concentrator Types Table 3-1.
Tables (continued) Contents Tables (continued) Table 4-12. Initial WRITE File-System Errors 4-30 Table 4-13. WRITE File-System Errors 4-32 Table 4-14. Initial READ Error Codes Table 4-15. Continuation READ Error Codes Table 4-16. Initial WRITE Error Codes Table 4-17. Continuation WRITE Error Codes 4-44 Table 5-1. BISYNC Multipoint Tributary Formats Table 5-2. Effect of TIMEOUT Value Table 5-3. CONTROL Operations for BISYNC Multipoint Tributary 5-8 Table 5-4.
Tables (continued) Contents Tables (continued) Table 7-8. Initial READ File-System Errors 7-26 Table 7-9. Continuation READ File-System Errors Table 7-10. WRITE File-System Errors 7-31 Table 7-11. Initial READ Error Codes Table 7-12. Continuation READ Error Codes Table 7-13. WRITE Operation Error Codes Table 8-1. TINET Multipoint Supervisor Formats Table 8-2. Effect of the Timeout Value Table 8-3. CONTROL Operations for TINET 8-5 Table 8-4.
Tables (continued) Contents Tables (continued) Table 10-3. Effect of Timeouts 10-7 Table 10-4. CONTROL Operations for Asynchronous Line Supervisor Table 10-5. SETMODE Operations for Asynchronous Line Supervisor 10-9 Table 10-6. Asynchronous Line Supervisor File-System Errors Table 10-7. General File-System Errors 10-12 Table 10-8. File-System Procedures for Read-Only Versus Normal Read Lines 10-13 Table 10-9.
Contents Envoy Application Programming Manual—427159-001 xxii
What’s New in This Manual Manual Information Envoy Application Programming Manual Abstract The Envoy subsystem provides general-purpose protocol support that enables application programs or terminals to communicate over communications lines on a ServerNet wide area network (SWAN) concentrator. This manual describes Envoy application programming, management functions, and the implementation of protocols used with Envoy. Product Version Envoy G-Series Supported Releases This manual supports G03.
What’s New in This Manual New and Changed Information Envoy Application Programming Manual—427159-001 xxiv
About This Manual This manual describes application programming of an Envoy subsystem running on a Compaq NonStop™ Himalaya S-series server. Who Should Use This Manual This manual is written for those who provide the following services for the server and the software environment at a particular site: • • • Planning Installation and configuration Maintenance, optimization, and troubleshooting How This Manual Is Organized This manual includes the following sections: Section Title This Section...
How This Manual Is Organized About This Manual Section Title This Section... 7 ADM-2 Multipoint Supervisor Protocol Describes the ADM-2 multipoint supervisor protocol, which enables an application process to act as the supervisor station in a centralized multipoint network consisting of specified terminals.
Related Documents and Online Tools About This Manual Related Documents and Online Tools This manual is part of the NonStop™ Himalaya S-series configuration and management manual set. Figure i shows the manuals you need to consult to run Envoy on NonStop™ Himalaya S-series servers. This supplement is highlighted in the figure. Figure i.
Stem Manual About This Manual Stem Manual • Himalaya S-Series Planning and Configuration Guide This guide describes planning considerations and is part of the NonStop™ Himalaya S-series server manual set. Core Configuration Manuals • DSM/SCM User’s Guide The Distributed Systems Management/Software Configuration Manager (DSM/SCM) is a system for the centralized planning, management, and installation of software on standalone and distributed Compaq systems.
Envoy Subsystem Manuals About This Manual • SCF Reference Manual for the Storage Subsystem This manual describes how to use the Subsystem Control Facility (SCF) to configure, control, and inquire about storage devices on a NonStop™ Himalaya S-series server.
TSM Manuals and Online Help About This Manual TSM Manuals and Online Help TSM manuals and online help provide information about using the TSM package to bring up and maintain NonStop™ Himalaya S-series servers. Figure ii shows the TSM manuals and online help. Figure ii.
WAN Wizard Installation and Configuration Tool About This Manual • TSM Low-Level Link Application online help TSM Low-Level Link online help is a Microsoft Windows online help system for the TSM Low-Level Link Application. TSM Low-Level Link Application online help describes how to perform tasks using the TSM Low-Level Link Application and provides quick-reference information, including how to use commands and dialog boxes.
Notation Conventions About This Manual Notation Conventions Hypertext Links Blue underline is used to indicate a hypertext link within text. By clicking a passage of text with a blue underline, you are taken to the location described. For example: This requirement is described under Backup DAM Volumes and Physical Disk Drives on page 3-2. General Syntax Notation The following list summarizes the notation conventions for syntax presentation in this manual. UPPERCASE LETTERS.
General Syntax Notation About This Manual | Vertical Line. A vertical line separates alternatives in a horizontal list that is enclosed in brackets or braces. For example: INSPECT { OFF | ON | SAVEABEND } … Ellipsis. An ellipsis immediately following a pair of brackets or braces indicates that you can repeat the enclosed sequence of syntax items any number of times. For example: M address-1 [ , new-value ]... [ - ] {0|1|2|3|4|5|6|7|8|9}...
Notation for Messages About This Manual !i,o. In procedure calls, the !i,o notation follows an input/output parameter (one that both passes data to the called procedure and returns data to the calling program). For example: error := COMPRESSEDIT ( filenum ) ; !i,o !i:i. In procedure calls, the !i:i notation follows an input string parameter that has a corresponding parameter specifying the length of the string in bytes.
Notation for Management Programming Interfaces About This Manual arranged either vertically, with aligned brackets on each side of the list, or horizontally, enclosed in a pair of brackets and separated by vertical lines. For example: proc-name trapped [ in SQL | in SQL file system ] { } Braces. A group of items enclosed in braces is a list of all possible items that can be displayed, of which one is actually displayed.
Change Bar Notation About This Manual Change Bar Notation Change bars are used to indicate substantive differences between this edition of the manual and the preceding edition. Change bars are vertical rules placed in the right margin of changed portions of text, figures, tables, examples, and so on. Change bars highlight new or revised information. For example: The message types specified in the REPORT clause are different in the COBOL85 environment and the Common Run-Time Environment (CRE).
1 Application Programming With Envoy The Envoy subsystem provides a data-link interface between transaction-oriented applications and data communications networks that allows your application program to use the Compaq station as a primary or secondary station in a point-to-point network or as a supervisor or tributary station in a centralized multipoint network (Figure 1-1). Figure 1-1. Communication Data Links Compaq System ATM Asynchronous Terminals Other System Byte-Synchronous Terminals CDT 003.
Application Programming With Envoy Management Functions Provided by Envoy Topics discussed in this section include: • • • • • • Management Functions Provided by Envoy on page 1-2 Envoy Subsystem Architecture on page 1-3 Protocols Supported on page 1-7 Using a Programmatic Interface on page 1-8 Configuration Tools on page 1-10 Guardian 90 File-System Procedure Calls on page 1-11 Management Functions Provided by Envoy The Envoy subsystem enables your application to perform the following tasks: • • • • •
Envoy Subsystem Architecture Application Programming With Envoy Envoy Subsystem Architecture An Envoy subsystem consists of the following: • • • Envoy I/O communications module Protocol and driver modules Physical line The I/O communications process serves as the interface to the file-system and management applications for the different communications lines.
Distributed Systems Management (DSM) Facility Application Programming With Envoy Distributed Systems Management (DSM) Facility Envoy supports the Distributed Systems Management (DSM) facilities provided by Compaq for subsystem management.
Control and Inquiry Interface Application Programming With Envoy SCF is a DSM tool in the operations environment. It is a unified command interface that simplifies the tasks of configuring, controlling, and collecting information about Compaq subsystems. When you use SCF, you can choose either to let a person perform an action (through a terminal) or to automate that action through a command (OBEY) file. SCF returns display and error-message output to a terminal or to a log file.
Application Programming With Envoy Event-Management Interface As shown in Figure 1-4, SCP sends each Envoy command to the appropriate process. Management applications send programmatic commands formatted as SPI buffers, and receive responses from the subsystem in the same format. In addition to communicating with SCF and your management application, TSM communicates with Envoy through the SCP process.
Protocols Supported Application Programming With Envoy Figure 1-5. Management Interfaces to Envoy: Event Management Event Management Service (EMS) Event Messages Collector Envoy Event Messages Envoy Event Log Management Application Event Management Interface Envoy Consumer Distributor Filter Event Messages Processes for Other Subsystems CDT 006.
Application Programming With Envoy Using a Programmatic Interface Table 1-1.
Application Programming With Envoy Object Types Like all other subsystems that support DSM, Envoy defines a set of object types—the kinds of objects that can be managed by Envoy—and a set of commands that can be performed on objects of these types. Object Types The WAN subsystem contains several SCF objects. Envoy uses the DEVICE, PROFILE, PROCESS and LINE objects. PROFILE The PROFILE object is a user-created, SCF object containing default modifier values pertaining to the communications line.
Configuration Tools Application Programming With Envoy Table 1-2.
Application Programming With Envoy Distributed Systems Management (DSM) Distributed Systems Management (DSM) The DSM product supports integrated management of system and network resources and operations.
Application Programming With Envoy Guardian 90 File-System Procedure Calls Envoy Application Programming Manual—427159-001 1- 12
2 Software Concepts This section describes the software concepts that apply to an Envoy data communications environment.
The Envoy Environment Software Concepts Each SWAN line can support these transmissions independent of the other lines. This enables a single SWAN concentrator to perform the functions of multiple controllers. Thus, customers migrating from Compaq NonStop ™ Himalaya K-series to S-series servers can preserve their investment in legacy devices. Envoy accesses the SWAN concentrator through Compaq NonStop™ TCP/IP and the ServerNet LAN Systems Access (SLSA) subsystems.
The Envoy Environment Software Concepts The protocol procedures determine the valid message formats, the sequence in which line operations are to be performed, and the appropriate corrective action to be taken when a line error occurs. Envoy currently supports the protocols shown in Table 2-1: Table 2-1.
File-System Procedures Software Concepts Figure 2-1. Application-Guardian 90-Envoy Relationship User Application Process Guardian 90 File-System Procedures (OPEN, CLOSE, READ, WRITE, CONTROL, and so forth) Envoy Envoy I/O Process Protocol Procedure Driver Procedure CDT 007.
File-System Procedures Software Concepts CONTROL DEFINELIST DEVICEINFO FILEINFO HALTPOLL OPEN READ[X] SETMODE SETMODENOWAIT WRITE[X] WRITEREAD[X] For further information on how these file-system procedures can be used with Envoy, see Appendix C, File-System Procedures. The most frequently used procedures are summarized here: CHANGELIST For a multipoint supervisor station, CHANGELIST enables or disables the polling of a particular station.
File-System Error Codes Software Concepts READ Accepts incoming data from a remote station. For a multipoint supervisor station, READ initiates polling of the tributary stations (polling stops when a station responds with data to the poll; subsequent polling resumes with the next station in the polling list). For a multipoint tributary station, READ enables the station to respond to polling or selection.
Message Transmission Software Concepts Example 2-1. Transmission CALL READ <--CALL READ <--. . . CALL READ <--CALL READ <--- message 1 message 2 \ message n EOT / | | |--> transmission | | To read a message, the application process receives the message through a call to the READ procedure. Envoy acknowledges each message when the application process issues a subsequent call to READ; the subsequent call then waits for the next message.
Message Formats Software Concepts Example 2-2 shows the following points: • Because the receipt of a message is not acknowledged until there is a subsequent READ call, the receiver’s message processing time must be less than the configured send timeout of the sender (the maximum amount of time that the sender waits for a reply).
Message Formats Software Concepts Messages must be formatted according to rules determined by the line protocol. Message formatting involves the embedding of specific control characters in messages. The purpose of the control characters is to indicate the type of message (such as a startof-header [SOH] message versus a text message) and whether the message consists of transparent text or normal text (DLE STX versus STX).
Line States Software Concepts Line States At any given time, an open communications line is in the CONTROL state, READ state, or WRITE state (Figure 2-2). Figure 2-2. Line States EOT CONTROL STATE READ READ WRITE READ READ STATE EOT WRITE STATE WRITE CDT 011.CDD CONTROL State The CONTROL state is the initial state of the line following a call to OPEN. The line reverts to the CONTROL state when a transmission completes (that is, when an EOT is sent or received).
Initial and Continuation Operations Software Concepts Initial and Continuation Operations File-system READ, WRITE, or WRITEREAD calls associated with a data communications transmission are categorized as being either initial operations or continuation operations: • • A call to the READ procedure while the line is in the CONTROL state is referred to as an initial READ. Subsequent calls to READ while the line is in the READ state are referred to as continuation READs.
Point-to-Point Operation Software Concepts Point-to-Point Operation Figure 2-3 shows the use of file-system procedure calls and error returns and the effects of the various line states in a point-to-point configuration. Two NonStop™ Himalaya servers are connected to one another over a nonswitched point-to-point line. An application process in each system acts as a station. Figure 2-3. Point-to-Point Operation Server A Server B Nonswitched Point-to-Point Line Application Process No.
Point-to-Point Operation Software Concepts Example 2-3. Monitor the Line for Incoming Messages Receiver Receiver CALL READ | | (READ completes) error = 162 CALL READ | | (READ completes) error = 162 Following the receipt of the "operation timed out" error, the line state is CONTROL. When a station has data to send, it bids for the line by calling the WRITE procedure. The bid (that is, an ENQ) is automatically sent across the line when you issue a WRITE while the controller is in the CONTROL state.
Point-to-Point Operation Software Concepts Example 2-4.
Multipoint Operation Software Concepts Multipoint Operation Figure 2-4 shows the use of file-system procedures, error returns, and the effects of the various line states in a multipoint configuration. Three NonStop™ Himalaya servers are connected to each other over a nonswitched multidrop line. An application process in one system acts as the supervisor station. The application processes in each of the other two systems act as tributary stations. Figure 2-4.
Station Addresses Software Concepts Station Addresses Each tributary station is identified by two types of addresses: a poll address and a select address. The poll address specifies the address that must be transmitted to solicit data from a station (note that a Compaq system acting as a tributary station can have several poll addresses).
Polling Operation Software Concepts Note. The application process appends an ENQ to the poll and select addresses. Additionally, if the sum of the address length + 1 (for the ENQ character) is odd, then the poll address must be preceded by an ASCII SYN character to pad the poll address out to an even length. For a tributary station, the address list contains the poll addresses and select addresses to which the station responds.
Polling Operation Software Concepts The supervisor station initiates polling by calling the READ procedure while the line is in the CONTROL state. Tributary stations, whether or not they have data to send, must monitor the line by calling the READ procedure. Polling Inactive Bit If a tributary station does not have data to send, it must set the polling inactive bit in the polling address in its address list. (See the DEFINELIST and CHANGELIST procedures in Appendix C, File-System Procedures.
Polling Operation Software Concepts Example 2-7.
Selection Operation Software Concepts • • The tributary indicates that the transmission is complete by sending an EOT character. An EOT is sent when the tributary calls the READ procedure following a call to the WRITE procedure (an EOT is also sent if CONTROL 13 is executed). The receipt of the EOT results in the second READ on the supervisor side completing with an error 163 (EOT received). The READ by the inactive tributary B does not complete.
Selection Operation Software Concepts Example 2-8.
Line-Error Handling Software Concepts the station’s poll and select addresses. The tributary’s READ completes when the station is either polled or selected or when an error occurs. Line-Error Handling During data transmission, certain error conditions can be expected to occur from time to time. The occurrence of an error condition causes Envoy to attempt recovery on behalf of the application process.
Software Concepts Programming Considerations for NonStop™ Himalaya Servers Programming Considerations for NonStop™ Himalaya Servers Programming for NonStop™ Himalaya servers affects application program design in two areas: • • Recovery from the failure of a path to a communications line (specifically, this means a failure of the processor module where the primary communications process is executing or a failure of the primary I/O channel to the communications device.
Programming Considerations for NonStop™ Himalaya Servers Software Concepts Example 2-9.
Programming Considerations for NonStop™ Himalaya Servers Software Concepts Example 2-7.
Software Concepts Programming Considerations for NonStop™ Himalaya Servers Envoy Application Programming Manual—427159-001 2- 26
3 BISYNC Point-To-Point Protocol The BISYNC point-to-point protocol allows an application process to act as a station in a binary synchronous (BISYNC) point-to-point network. One of the implementations of this protocol is for a Computer Based Terminal (CBT) in the Society for Worldwide Interbank Financial Telecommunications (SWIFT) network. There are some special considerations for the Envoy-SWIFT implementation, which are described in this section.
Envoy BISYNC Features BISYNC Point-To-Point Protocol • Allows a conversational reply to a conversational reply Details of the Envoy-SWIFT protocol are discussed under Envoy-SWIFT Considerations on page 3-3.
BISYNC Point-To-Point Protocol Envoy-SWIFT Considerations Envoy-SWIFT Considerations The Envoy-SWIFT protocol provides a link-level interface for users planning to interface to the Society for Worldwide Interbank Financial Telecommunications. The Compaq Envoy-SWIFT point-to-point protocol has been granted dispensation from SWIFT for certification tests 47, 49, and 69. The SWIFT certification tests are described in the SWIFT User Manuals TEC 4.5 (20 May 1976) and OPS 10.5.6 (20 June 1978).
BISYNC Point-To-Point Protocol Application Process Interface Application Process Interface The application process acting as a station in a BISYNC point-to-point network interacts with Envoy and the remote station by way of Guardian 90 file-system procedure calls.
BISYNC Point-To-Point Protocol Sending EOT Sending EOT The sender indicates the end of a data transmission by sending an end-of-transmission (EOT) sequence to the receiver.
Timeouts BISYNC Point-To-Point Protocol SWIFT Retry Values The SWIFT protocol specifies two fixed retry count values that are required and cannot be altered by the SETMODE procedure. These retry values are shown in Table 3-3. Table 3-3. SWIFT Retry Values Number of Retries Protocol Sequence 30 WACK ENQ There can be up to 30 exchanges of the WACK ENQ sequence, which indicates a temporary not-ready condition to the sender. This condition should be followed by receiving text.
BISYNC Point-To-Point Protocol Limited Conversational Mode Table 3-4. Effect of Timeout Value (page 2 of 2) Procedure Effect of Timeout Value CONTROL 11 or 17 Determines the period of time Envoy waits for the DSR (data set ready) signal sent by a modem when a transmission begins. If Envoy does not receive the DSR signal within 8 timeout periods (up to 327.67 seconds), it returns a modem-error indication to the application process.
File-System Procedures BISYNC Point-To-Point Protocol File-System Procedures The application process uses the following Guardian 90 file-system procedures to interact with Envoy and to communicate with a remote BISYNC point-to-point station: AWAITIO Waits for completion of an outstanding nowait I/O operation. CLOSE Terminates access to a data communications line. CONTROL Performs various line control operations, as shown in Table 3-5. Table 3-5.
File-System Procedures BISYNC Point-To-Point Protocol OPEN Establishes communications with a line. A line can be open by only one process (and its backup) at a time. READ Monitors the line and accepts any incoming messages. The first call to READ following the call to OPEN for the line sets the data terminal ready (DTR) signal.
File-System Procedures BISYNC Point-To-Point Protocol Table 3-6. SETMODE Operations for BISYNC Point-to-Point (page 2 of 2) Operation Parameter Description .<13> 0: Secondary station 1: Primary station .
Message Formats BISYNC Point-To-Point Protocol However, the Compaq implementation allows the station receiving the conversational reply to respond with a conversational reply. Multileaving conversational mode permits each station to maintain contact with the other by responding with text or with ACK each time text or ACK is received from the other station. WRITEREAD sends the reply to the station giving the previous input and obtains the other station's reply.
BISYNC Point-To-Point Protocol Normal Text Messages must be formatted according to BISYNC rules. Prior to transmitting a message, the application process must place the specific BISYNC control characters for a particular message type (such as, heading, text, transparent text, and so on) in the message. When a message is received, the control characters are returned in the data to indicate the type of message received.
Headings BISYNC Point-To-Point Protocol Headings Headings use the formats shown in Table 3-7: Table 3-7.
BISYNC Point-To-Point Protocol Intermediate Text Blocking Normal Text With ITBs Normal text with intermediate text blocks is indicated by a nonzero intermediate block length and messages having the following form: message = STX—text—ITB...—text—ETB message = STX—text—ITB...—text—ETX (message length = 2 + text length + number of intermediate blocks - 1) or message = SOH—heading—STX—text—ITB...—text—ETB message = SOH—heading—STX—text—ITB...
BISYNC Point-To-Point Protocol ID Exchange ID Exchange When performing an ID exchange, the application process must format the ID in its buffer by appending the appropriate control characters: • An ID exchange message from the caller is indicated by a message having the following form: message = ID—ENQ (message length = 1 + ID length) • An ID exchange message from the called station is indicated by a message having the following form: message = ID—ACK0 (caller’s ID okay) message = ID—WACK (caller’s ID
BISYNC Point-To-Point Protocol File-System Errors File-System Errors Upon completion of a file-system request, the application process should check for the Guardian 90 file-system error codes listed in Table 3-8. Table 3-8.
BISYNC Point-To-Point Protocol Line Action by Procedure Call Line Action by Procedure Call This subsection describes the line action of the following procedures.
READ Procedure BISYNC Point-To-Point Protocol Example 3-1. Initial Read (Line in CONTROL State) Local Remote line state - CONTROL CALL READ (...) | | | ACKD --> | | <--ENQ (bid) <--message 1 (READ completes) error = 0 line state = READ Note that the initial message from the remote station is not acknowledged by the initial READ. The subsequent READ acknowledges the initial message. A timeout (Example 3-2) can occur while the local station is waiting for a line bid from the remote station.
BISYNC Point-To-Point Protocol READ Procedure Table 3-10. Errors on Initial READ for BISYNC Point-to-Point (page 2 of 2) Error Number Description Resultant Line State 162 Operation timed out. A line bid was not received within the timeout and retry. CONTROL 163 EOT received. An EOT was received while waiting for the line bid. CONTROL 164 For switched lines, the disconnect sequence (DLE EOT) was received. Data terminal ready is cleared.
READ Procedure BISYNC Point-To-Point Protocol Example 3-3. Continuation READ (Line in READ State) Local Remote line state = READ CALL READ(...) | | ACKn --> | (READ completes) error = 0 line state = READ CALL READ (...) | | ACKn --> | (READ completes) error \ 163 line state = CONTROL <-- message n <-- EOT The file-system errors shown in Table 3-11 can occur on a continuation READ. Table 3-11.
READ Procedure BISYNC Point-To-Point Protocol Table 3-11. Errors on Continuation READ for BISYNC Point-toPoint (page 2 of 2) Error Number Resultant Line State Description 172 Reply not proper for protocol. The data received while waiting for a line bid or for text was not proper for the BISYNC protocol. CONTROL 173 Transmission error. The message received was in error and a NAK sequence was sent the number of times specified by the retry value. CONTROL 177 Text overrun.
WRITE Procedure BISYNC Point-To-Point Protocol Example 3-5. Initial READ of ID (Line in CONTROL State) Local Remote line state = DISCONNECT CALL READ)...) | | | (READ completes) error = 0 line state = DISCONNECT <-- ID ENQ (bid) Note that the ID is not acknowledged by the initial READ. Following the receipt of the ID sequence, the called station checks the ID for validity.
WRITE Procedure BISYNC Point-To-Point Protocol Example 3-6. Initial WRITE (Line in CONTROL State) Local Remote line state = CONTROL CALL WRITE(...) | | (bid) enq --> | | message 1 --> | | (WRITE completes error = 0 line state = WRITE <-- ACK0 <-- ACK1 The file-system errors shown in Table 3-12 can occur on an initial WRITE. Table 3-12. Errors on Initial WRITE for BISYNC Point-to-Point (page 1 of 2) Error Number Description Resultant Line State 0 No error.
WRITE Procedure BISYNC Point-To-Point Protocol Table 3-12. Errors on Initial WRITE for BISYNC Point-to-Point (page 2 of 2) Error Number Description Resultant Line State 171 No response to line bid. The line bid was attempted the number of times specified by the retry value. CONTROL 172 Reply not proper for protocol. The data received while waiting for a line bid or for text was not proper for the BISYNC protocol. CONTROL 173 Transmission error.
BISYNC Point-To-Point Protocol WRITEREAD Procedure (Limited Conversational Exchange) Table 3-13. Errors on Continuation WRITE With BISYNC Point-to-Point Error Number Description Resultant Line State 0 No error. Message in the buffer of the application process is written to the remote station. WRITE 160 Request is invalid for device state; protocol error. unknown 161 Impossible event occurred for line state. unknown 163 EOT received. An EOT was received while waiting for the line bid.
BISYNC Point-To-Point Protocol WRITEREAD Procedure (Limited Conversational Exchange) READ. If only an acknowledgment is received, the count read parameter is returned with a value of two (includes the MCW) and the line state is WRITE. Example 3-8. Initial WRITEREAD (Line in CONTROL State) Local Remote line state = CONTROL CALL WRITEREAD(...
BISYNC Point-To-Point Protocol WRITEREAD Procedure (Limited Conversational Exchange) Example 3-9. Continuation WRITEREAD (Line in WRITE State) Local Remote line state = WRITE CALL WRITEREAD(...) | message n --> | | (WRITE completes) error = 0 line state = WRITE if ACKn received or line state = READ if message received <-- ACKn or message 1 The file-system errors for a continuation WRITEREAD are the same as for a continuation WRITE.
BISYNC Point-To-Point Protocol WRITEREAD Procedure (Limited Conversational Exchange) If an ID ACK0 sequence is returned, the remote station has accepted the ID (and the line bid) and the line state is WRITE. At this point, the caller should verify the ID that was returned. If the ID is not valid, the caller disconnects the line (or performs some corresponding action).
BISYNC Point-To-Point Protocol WRITEREAD Procedure (Limited Conversational Exchange) Example 3-11. WRITEREAD Procedure (ID Exchange by Called Station) Local Remote line state = CONTROL CALL WRITEREAD(...
BISYNC Point-To-Point Protocol WRITEREAD Procedure (Limited Conversational Exchange) Table 3-14. Errors on Multileaving Conversational WRITEREAD Error Number Description Resultant Line State 0 No error. Message is returned to buffer of the application process. CONVERSATIONAL 160 Request is invalid for device state; protocol error. unknown 161 Impossible event occurred for line state. unknown 162 Operation timed out.
CONTROL Procedure (Send EOT) BISYNC Point-To-Point Protocol CONTROL Procedure (Send EOT) The EOT sequence is used to relinquish line control or to reset the line following a READ error. The application sends EOT by calling the CONTROL procedure and specifying operation 13 (Example 3-13). Example 3-13.
CONTROL Procedure (Send TTD) BISYNC Point-To-Point Protocol CONTROL Procedure (Send TTD) The TTD sequence is used when the application process is not ready to transmit data but does not want to relinquish the line. The application sends TTD by calling the CONTROL procedure and specifying operation 16 (Example 3-16). In the SWIFT protocol, up to 30 consecutive TTD sequences can be issued; if a station receives 31 TTD sequences, it drops the communications link. Example 3-16.
Initial READ Operation BISYNC Point-To-Point Protocol Figure 3-1. BISYNC Point-to-Point Initial READ CALL READ...
Initial READ Operation BISYNC Point-To-Point Protocol Figure 3-2 shows the action of the local station using the SWIFT BISYNC Point-toPoint protocol in response to line conditions on an initial READ. Figure 3-2. SWIFT Point-to-Point Initial READ CALL READ...
Continuation READ Operation BISYNC Point-To-Point Protocol Continuation READ Operation Figure 3-3 shows the action of the local station using the standard BISYNC Point-toPoint protocol in response to line conditions on a continuation READ. Figure 3-3. BISYNC Point-to-Point Continuation READ CALL READ...
Continuation READ Operation BISYNC Point-To-Point Protocol Figure 3-4 shows the action of the local station using the SWIFT BISYNC Point-toPoint protocol in response to line conditions on a continuation READ. Figure 3-4. SWIFT Point-to-Point Continuation READ CALL READ...
Initial WRITE Operation BISYNC Point-To-Point Protocol Initial WRITE Operation Figure 3-5 shows the action of the local station using the standard BISYNC Point-toPoint protocol in response to line conditions on an initial WRITE. Figure 3-5. BISYNC Point-to-Point Initial WRITE CALL WRITE...
Initial WRITE Operation BISYNC Point-To-Point Protocol Figure 3-6 shows the action of the local station using the SWIFT BISYNC Point-toPoint protocol in response to line conditions on an initial WRITE. Figure 3-6. SWIFT Point-to-Point Initial WRITE CALL WRITE...
Continuation WRITE Operation BISYNC Point-To-Point Protocol Continuation WRITE Operation Figure 3-7 shows the action of the local station using the standard BISYNC Point-toPoint protocol in response to line conditions on a continuation WRITE. Figure 3-7. BISYNC Point-to-Point Continuation WRITE CALL WRITE...
Continuation WRITE Operation BISYNC Point-To-Point Protocol Figure 3-8 shows the action of the local station using the SWIFT BISYNC Point-toPoint protocol in response to line conditions on a continuation WRITE. Figure 3-8. SWIFT Point-to-Point Continuation WRITE CALL WRITE...
WRITEREAD Operation BISYNC Point-To-Point Protocol Note. The SWIFT protocol has a fixed value for retry count of 30 for the WACK ENQ sequence. WRITEREAD Operation The normal WRITEREAD operation acts as if a WRITE were followed immediately by a READ. Figure 3-9 shows the action of the local station in response to line conditions on a multileaving conversational WRITEREAD. Figure 3-9. BISYNC Point-to-Point Multileaving WRITEREAD CALL WRITEREAD...
BISYNC Point-To-Point Protocol Programming Examples Programming Examples The examples in this subsection show the following operations: • Line Bid on page 3-42 Bid for line and then transmit message to remote (remote station then reads message) • • • Limited Conversational Mode on page 3-49 Use of Reverse Interrupt (RVI) on page 3-53 ID Exchange on page 3-55 Line Bid The following programming example demonstrates a BISYNC Point-to-Point line bid by the local station and the corresponding READ by the
Line Bid BISYNC Point-To-Point Protocol Figure 3-10. BISYNC Point-to-Point Line Bid Local Remote Start Start OPEN the Line OPEN the Line Monitor the Line (READ) Monitor the Line (READ) Yes Line Times Out Time Out? No Anything to Send? Yes Format the Message Send the Message (WRITE) No Yes EOT? No Something Read Process Message CDT 022.
Line Bid BISYNC Point-To-Point Protocol Example 3-17.
Line Bid BISYNC Point-To-Point Protocol Example 3-18. Program Code for read^text and write^text (Page 1 of 5) INT termfnum, linefnum, opfnum, lerror, linestate, .termbuf[0:35]; ! data declarations. ! ! ! ! line state: 0 = cntl, ! 1 = read, 2 = write. LITERAL STX = 2, ETX = 3, DLE = %20, max^line = 40, readcnt = max^line * 2, cntlstate = 0, readstate = 1, writestate = 2, timeout = 162, eot^rcvd = 163; ! end of global declarations.
Line Bid BISYNC Point-To-Point Protocol Example 3-18. Program Code for read^text and write^text (Page 2 of 5) ! ! ! ! This procedure is used to write a message to the remote station. This procedure embeds the appropriate line control characters. The file-system error number associated with the line is returned. INT PROC write^text ( text , text^len ); INT .text, .text^len; BEGIN INT .linebuf[-1:max^line-1], writecnt, lerror; ! data declarations. ! ! STRING .slinebuf := @linebuf '<<' 1, .
BISYNC Point-To-Point Protocol Example 3-18. Program Code for read^text and write^text (Page 3 of 5) ! This procedure checks the home terminal for a completion. ! If a completion was made, another WRITEREAD is issued. INT PROC check^term ( text ); INT .text; BEGIN INT countread := 0, error; INT(32) wait^type; wait^type := IF linestate = writestate THEN -1D ELSE 0D; CALL AWAITIO ( termfnum,, countread,, wait^type ); CALL FILEINFO( termfnum, error ); IF error <> 40 THEN ! operation completed.
BISYNC Point-To-Point Protocol Example 3-18. Program Code for read^text and write^text (Page 4 of 5) PROC example MAIN; BEGIN INT .buf[0:max^line-1], ! general purpose buffer. count; ! read the start-up message to identify home terminal. buf ':=' ["$RECEIVE", 8 * [" "]]; CALL OPEN (buf,count); CALL READ (count,buf,66); CALL CLOSE(count); ! open the home terminal. CALL OPEN (buf[9], termfnum, 1); ! nowait. IF < THEN CALL ABEND; ! open the line.
BISYNC Point-To-Point Protocol Limited Conversational Mode Example 3-18. Program Code for read^text and write^text (Page 5 of 5) ELSE IF lerror = timeout AND linestate = cntlstate THEN BEGIN lerror := 0; WHILE (count := check^term(buf)) AND NOT lerror DO lerror := write^text ( buf, count ); linestate := cntlstate; END ELSE ! some other error. IF linestate = readstate THEN BEGIN CALL CONTROL ( linefnum, 13 ); ! send EOT. linestate := cntlstate; END; END; ! while 1 do loop. END; ! example.
BISYNC Point-To-Point Protocol Limited Conversational Mode The remote station makes all transmissions except the last with calls to the WRITE procedure; the last message is transmitted with a call to the WRITEREAD procedure. The local station receives all transmissions with calls to the READ procedure. When the last message is read by the local station, it makes a conversational reply with a call to the WRITEREAD procedure.
Limited Conversational Mode BISYNC Point-To-Point Protocol Example 3-19.
Limited Conversational Mode BISYNC Point-To-Point Protocol In the next example of conversational exchange (Example 3-20), the local station is the sender and the remote station is the receiver. The local station makes all transmissions with calls to the WRITEREAD procedure. This use of the WRITEREAD procedure allows the remote station the option of replying to each message. (This option might be used to report an error condition to the local station.
BISYNC Point-To-Point Protocol Use of Reverse Interrupt (RVI) Use of Reverse Interrupt (RVI) When receiving text, the RVI control sequence can be sent in place of a positive acknowledgment. RVI is used to inform the sending station that the receiver has a message to send and, therefore, wants to bid for the line. The sender treats the receipt of the RVI sequence as a positive acknowledgment of the message.
Use of Reverse Interrupt (RVI) BISYNC Point-To-Point Protocol Example 3-21.
ID Exchange BISYNC Point-To-Point Protocol ID Exchange The use of an ID exchange on a switched line permits the stations to verify that they each have a valid authorization. In the next example (Example 3-22), both the local and remote stations are Compaq systems. The local station is the caller. The conversational exchange shows the file-system calls and the control sequences associated with an ID exchange sequence. Example 3-22.
BISYNC Point-To-Point Protocol • • ID Exchange ID NAK: The negative acknowledgment indicates that the station is not ready to receive data. If this is returned, the WRITEREAD by the caller completes with line state = CONTROL, error = 0. ID WACK: The wait for acknowledgment indicates that the station is temporarily not ready to continue. If ID WACK is returned, Envoy waits for one timeout interval then reissues the ID ENQ sequence on behalf of the caller.
4 BISYNC Centralized Multipoint Supervisor Protocol The BISYNC centralized multipoint supervisor protocol allows a network consisting of two or more stations to communicate over a leased multidrop line. One station is designated as the supervisor and the other stations are designated as tributaries. This section describes the binary synchronous communication protocol used by an application process acting as a supervisor station in a BISYNC centralized multipoint network.
BISYNC Centralized Multipoint Supervisor Protocol Application Process Interface Table 4-1.
BISYNC Centralized Multipoint Supervisor Protocol Polling Polling Polling is initiated when the supervisor station calls the READ procedure while the line is in a CONTROL state. This call also reads the first message from the responding tributary station. The supervisor station must then call READ for each additional message from the tributary station. Messages are read until an end-of-transmission (EOT) indication is received from the tributary station.
Polling BISYNC Centralized Multipoint Supervisor Protocol Figure 4-1. BISYNC Multipoint Supervisor Polling CALL OPEN (nowait) CALL DEFINELIST... CALL READ... The Network is Polled No Did a Polled Station Respond with Text? Yes READ Completes No EOT Recd? Yes CALL READ... Read Next Message from Tributary Message from the Tributary Station is Processed No Any Messages to Send ? Yes CDT 023.
ASCII and EBCDIC Line Code BISYNC Centralized Multipoint Supervisor Protocol The supervisor station initiates selection by calling the WRITE procedure while the line is in a CONTROL state. This call also writes the first message to the selected tributary station. The supervisor station must then call WRITE for each additional message to be transmitted.
Timeouts BISYNC Centralized Multipoint Supervisor Protocol • • Set a retry count value for each line when issuing the ADD DEVICE command (RETRIES modifier). Alter the retry count value using the SETMODE 15 procedure. If an error condition persists after the operation has been retried the specified times, Envoy returns an error indication to the application process that requested the operation. Timeouts The protocol uses timeouts to detect error conditions.
BISYNC Centralized Multipoint Supervisor Protocol Limited Conversational Mode procedure. Therefore, the application process at the supervisor station must process the message within the timeout period specified for the tributary station.
BISYNC Centralized Multipoint Supervisor Protocol File-System Procedures Table 4-4.
BISYNC Centralized Multipoint Supervisor Protocol File-System Procedures READ Solicits data from a remote station. A call to READ while the line is in the CONTROL state (an initial READ) causes Envoy to initiate polling of the tributary stations specified in the currently defined poll list. When a tributary station responds to the poll by sending a message, polling halts, Envoy returns the tributary's message to the application process, and the READ completes.
BISYNC Centralized Multipoint Supervisor Protocol Address-List Format WRITE Transmits data to a tributary station. A call to WRITE while the line is in the CONTROL state (an initial WRITE) causes Envoy to select the station indicated by the entry number value in the message control word. Envoy transmits the associated text block from the application's write buffer to the tributary station when the tributary acknowledges the selection.
Station Address BISYNC Centralized Multipoint Supervisor Protocol Example 4-1. Address List Format station address, entry 0 station address, entry 0 . . . station address, entry pn-1 station address, entry pn station address, entry pn+1 . . .
Select List BISYNC Centralized Multipoint Supervisor Protocol Select List The select list immediately follows the poll list in the address list. It contains one entry for each address that may be selected (the number of entries minus the poll count). The entries in the select list must correspond exactly to the entries in the poll list. The following example (Example 4-2) shows how to build an address list Example 4-2.
BISYNC Centralized Multipoint Supervisor Protocol • Polling Note that the select list contains multiple entries per station. This permits selection of individual devices (such as a printer or card punch) at the remote station. Polling Polling is initiated by issuing a READ call while the line is in the CONTROL state.
BISYNC Centralized Multipoint Supervisor Protocol Polling Type Figure 4-3. BISYNC Multipoint Supervisor Continuous Poll Sequence CALL OPEN... CALL DEFINELIST... CALL READ... Poll-List Entry 0 EOT Poll-List Entry 1 EOT Poll-List Entry pn - 1 EOT CDT 025.CDD If a polled station responds with text, the READ completes with the line in the READ state and an error 0 (operation successful).
BISYNC Centralized Multipoint Supervisor Protocol Polling Type Example 4-3. Continuous Polling poll^type := 0; CALL DEFINELIST (linefnum,addr^list,addr^size,num^entries, poll^count,poll^type); IF < THEN ... CALL READ (linefnum, linebuf,..); IF < THEN ... The READ completes either when a station responds to a poll with a message or when a line error is detected. If a station responds with a message, the entry number of the station in the poll list is returned in linebuf.
BISYNC Centralized Multipoint Supervisor Protocol Polling Type Figure 4-4. BISYNC Multipoint Supervisor Noncontinuous Poll Sequence CALL OPEN... CALL DEFINELIST... CALL READ... Poll Count = (Polling Type) from DEFINELIST Poll Entry 0 EOT Poll Entry 1 EOT Poll Entry pn-1 EOT Poll Count = Poll Count - 1 No Poll Count = 0? Yes Error = 176 CDT 027.CDD Example 4-4 shows how to change a line's polling type from continuous to noncontinuous. Example 4-4.
Polling Type BISYNC Centralized Multipoint Supervisor Protocol The supervisor polls each station a maximum of ten times for each call to the READ procedure when the line is in the CONTROL state. If polling is in progress, the change does not take effect until the next call to READ. Specific Polling Specific polling occurs when a designated station is polled once. Polling of only one specified station is designated with a call to the CONTROL procedure.
BISYNC Centralized Multipoint Supervisor Protocol Polling Interval Polling Interval The polling interval specifies how long Envoy waits, following a pass through the poll list, before beginning a subsequent pass through the poll list. Figure 4-5 shows the polling interval. Figure 4-5. BISYNC Multipoint Supervisor Polling Interval CALL OPEN... CALL DEFINELIST... CALL READ... Poll Entry 0 EOT Poll Entry 1 EOT Poll Entry pn-1 EOT Yes Done? No Delay for Poll Interval CDT 028.
BISYNC Centralized Multipoint Supervisor Protocol Poll State Poll State The poll-state bit is associated with each address in the poll list. The poll-state bit is the most significant bit of the first element of a station address; that is, station address.0.
Poll State BISYNC Centralized Multipoint Supervisor Protocol Selective Polling (Before Calling DEFINELIST) Example 4-6 shows how to disable polling for a specific station using the poll-state bit in the address list. Example 4-6. Disable Polling LITERAL addr^size = 3, num^entries = 8, ENQ SYN poll^count no^poll = = = = 5, %26, 3, %200; ! ! ! ! ! ! ! STRING .saddr^list[ 0 : addr^size * ! address list.
BISYNC Centralized Multipoint Supervisor Protocol Nonresponding Station List Nonresponding Station List The nonresponding station list is internal to Envoy. It keeps track of stations that do not respond to polling. If a polled station does not respond with either an EOT sequence or a message within the timeout period specified for the line, its address is entered into the nonresponding station list. Stations in the nonresponding station list are referred to as being partially disabled.
BISYNC Centralized Multipoint Supervisor Protocol Message Formats Message Formats A message is defined as the information transmitted over a communication line as a result of a single call to the READ or WRITE procedure.
Normal Text BISYNC Centralized Multipoint Supervisor Protocol • Intermediate Text Blocks on page 4-23 Normal Text Normal text is indicated by messages having the following form: message = STX—text—ETB message = STX—text—ETX (message length = 2 + text length) Transparent Text Transparent text is indicated by messages having the following form: message = DLE STX—text—ETB message = DLE STX—text—ETX (message length = 3 + text length) Transparent mode is initiated by inserting a DLE control character before
BISYNC Centralized Multipoint Supervisor Protocol Intermediate Text Blocks another block to be immediately sent without the need for line turnaround (that is, without a receiver acknowledging each block) as is the case with normal blocking. If an error is detected during one of the block checks, a NAK is returned only after an ETB or ETX is received. Then, the entire message containing all of the intermediate blocks is retransmitted.
BISYNC Centralized Multipoint Supervisor Protocol File-System Errors File-System Errors Upon completion of a file-system request, the multipoint supervisor application process should check for the Guardian 90 file-system error codes listed in Table 4-8. Table 4-8.
BISYNC Centralized Multipoint Supervisor Protocol Line Action by Procedure Call Line Action by Procedure Call This subsection describes the BISYNC control sequences transmitted because of calls to file-system procedures. The actions of file-system procedures in response to line states and the reception of selected control sequences are also described.
READ Procedure BISYNC Centralized Multipoint Supervisor Protocol Example 4-7. Initial READ (Line in CONTROL State) Supervisor (Local) line state = CONTROL Tributary (Remote) CALL READ(...) | | EOT SYN-poll addr 1-ENQ --> <-- EOT | EOT SYN-poll addr 2-ENQ --> | <-- EOT | . | . . | . . | . | EOT SYN-poll addr n-ENQ --> | <-- message 1 | (Initial READ completes) error = 0 line state = READ MCW.<8:15> contains the entry number for station "n" Note.
READ Procedure BISYNC Centralized Multipoint Supervisor Protocol Table 4-10. Initial READ File-System Errors (page 2 of 2) Error Number Description Resultant Line State 172 Reply not proper for protocol. The data received while waiting for a response to the poll sequence was not proper for the BISYNC protocol. CONTROL 173 Transmission error. The message received was in error and a NAK sequence has been sent the number of times specified by the retry value.
READ Procedure BISYNC Centralized Multipoint Supervisor Protocol Note. If poll on EOT is enabled, the supervisor polls the next station. The error 163 is not returned to the application. Table 4-11 shows the file-system errors that may occur on a continuation READ. Table 4-11. Continuation READ File-System Errors Error State Description Resultant Line State 0 No error. The message is returned to buffer of application process. READ 160 Request is invalid for device state; protocol error.
WRITE Procedure BISYNC Centralized Multipoint Supervisor Protocol The file-system errors applicable to an initial READ from the CONTROL state also apply to an initial READ from the WRITE state. WRITE Procedure The WRITE procedure is used to select and transmit messages to a tributary station. While messages are being sent, the line is in the WRITE state. The line returns to the CONTROL state when the supervisor station sends an EOT sequence (to indicate the completion of the transmission).
WRITE Procedure BISYNC Centralized Multipoint Supervisor Protocol Table 4-12. Initial WRITE File-System Errors (page 2 of 2) Error State Description Resultant Line State 165 RVI received. The tributary transmitted a reverse interrupt sequence as a positive acknowledgment to the message. WRITE 166 ENQ in response to selection. CONTROL 167 EOT in response to selection. The tributary rejected the selection. CONTROL 168 NAK in response to selection. CONTROL 169 WACK in response to selection.
WRITE Procedure BISYNC Centralized Multipoint Supervisor Protocol Example 4-11. Continuation WRITE (Line in WRITE State) Supervisor (Local) Tributary (Remote) line state = WRITE CALL WRITE(...) | message 2 --> | (WRITE completes) error = 0 line state = WRITE <-- ACK0 Table 4-13 lists the possible errors and their descriptions while the line is in the WRITE state. Table 4-13. WRITE File-System Errors (page 1 of 2) Error State Description Resultant Line State 0 No error.
BISYNC Centralized Multipoint Supervisor Protocol WRITEREAD Procedure (Conversational Exchange) Table 4-13. WRITE File-System Errors (page 2 of 2) Error State Description Resultant Line State 177 Text overrun on selection. The length of the response received exceeds two characters (text was received rather than a control character). The selection or transmission was attempted the number of times specified by the retry value.
BISYNC Centralized Multipoint Supervisor Protocol CONTROL Procedure (Send EOT) Continuation WRITEREAD (Line in READ State and Last State is READ) This operation is not permitted for limited conversational mode according to the BISYNC protocol. A second call to WRITEREAD while the line is in the READ state would be an attempt to acknowledge two consecutive messages with messages.
CONTROL Procedure (Send WACK) BISYNC Centralized Multipoint Supervisor Protocol CONTROL Procedure (Send WACK) The WACK sequence is used following a READ to indicate a temporary not-ready condition while maintaining the communications link. The applications sends WACK by calling the CONTROL procedure and specifying operation 14 (Example 4-14). Example 4-14.
BISYNC Centralized Multipoint Supervisor Protocol Line-Error Handling Line-Error Handling The figures and error code descriptions in this subsection show how Envoy handles lineerrors for BISYNC multipoint supervisor protocol READ and WRITE operations.
Initial READ Operation BISYNC Centralized Multipoint Supervisor Protocol Figure 4-6. BISYNC Multipoint Supervisor Initial READ CALL READ...
BISYNC Centralized Multipoint Supervisor Protocol Initial READ Operation Table 4-14 lists the error codes that can occur during an initial READ operation. Table 4-14.
Continuation READ Operation BISYNC Centralized Multipoint Supervisor Protocol Continuation READ Operation Figure 4-7 shows the action of the supervisor station in response to line conditions on a continuation READ. Figure 4-7. BISYNC Multipoint Supervisor Continuation READ CALL READ...
BISYNC Centralized Multipoint Supervisor Protocol Continuation READ Operation Table 4-15 shows the error codes that can occur during a continuation READ operation. Table 4-15.
Initial WRITE Operation BISYNC Centralized Multipoint Supervisor Protocol Initial WRITE Operation Figure 4-8 lists the action of the supervisor station in response to line conditions on an initial WRITE, but prior to the first message being sent. Figure 4-8. BISYNC Multipoint Supervisor Initial WRITE CALL WRITE...
BISYNC Centralized Multipoint Supervisor Protocol Initial WRITE Operation Table 4-16 lists the error codes that can occur during an initial WRITE operation. Table 4-16.
Continuation WRITE Operation BISYNC Centralized Multipoint Supervisor Protocol Continuation WRITE Operation Figure 4-9 shows the action of the supervisor station in response to line conditions on a continuation WRITE and the first message being sent on an initial WRITE. Figure 4-9. BISYNC Multipoint Supervisor Continuation WRITE CALL WRITE...
BISYNC Centralized Multipoint Supervisor Protocol Programming Examples Table 4-17 lists the error codes that can occur during a continuation WRITE operation. Table 4-17.
Programming Examples BISYNC Centralized Multipoint Supervisor Protocol Figure 4-10. BISYNC Multipoint Supervisor Station Addresses Tributaries Supervisor S 0 Poll Address = PA Select Address = Sa 1 Poll Address = PB Select Address = Sb 2 Poll Address = PC Select Address = Sc 3 Poll Address = PC Select Address = Sd CDT 033.
Programming Examples BISYNC Centralized Multipoint Supervisor Protocol Figure 4-11 shows the flow of the multipoint supervisor READ-WRITE operation. Figure 4-11.
Programming Examples BISYNC Centralized Multipoint Supervisor Protocol The following conversational exchange (Example 4-17) shows the control sequences associated with polling the network. The polling type is specified as noncontinuous; one pass is made through the poll list with each call to the READ while the line is in the CONTROL state. In the following example, stations 0 and 1 have nothing to send, station 2 does. Example 4-17.
Programming Examples BISYNC Centralized Multipoint Supervisor Protocol Example 4-19 shows the sequence when polling is resumed (and no station has data to send). Example 4-19. Polling Resumed Supervisor (Local) line state = WRITE CALL READ | EOT --> | | (poll) EOT SYN | | (poll) EOT SYN | | (poll) EOT SYN | | (poll) EOT SYN (READ completes) error = 176 line state = CONTROL MCW.
Programming Examples BISYNC Centralized Multipoint Supervisor Protocol Example 4-20 shows the program code in each process: Example 4-20. Program Code for Poll and Select Procedures (Page 1 of 7) ! ! ! ! ! ! ! ! ! ! ! ! line buffer message format (transparent text) byte [0] [2] [3] [4] [5] [7] MCW DLE STX ,--ETX MCW = message control word s = source station identity, one byte: S = supervisor, 0:3 = tributary d = destination station identity. INT termfnum, .
BISYNC Centralized Multipoint Supervisor Protocol Programming Examples Example 4-20. Program Code for Poll and Select Procedures (Page 2 of 7) STRING .saddr^list[ 0 : [ SYN, "PA", SYN, "PB", SYN, "PC", SYN, "PD", SYN, "Sa", SYN, "Sb", SYN, "Sc", SYN, "Sd", addr^size * num^entries * 2 ENQ, ! entry 0, station ENQ, ! entry 1, station ENQ, ! entry 2, station ENQ, ! entry 3, station ENQ, ! entry 4, station ENQ, ! entry 5, station ENQ, ! entry 6, station ENQ ]; ! entry 7, station 0 1 2 3 0 1 2 3 1] := poll.
BISYNC Centralized Multipoint Supervisor Protocol Programming Examples Example 4-20. Program Code for Poll and Select Procedures (Page 3 of 7) ! This procedure checks the home terminal for a completion. ! The following values are returned: ! ! 0 = no completion. ! 1 = completion. ! 2 = end of file. ! 3 = recoverable error occurred. ! 4 = nonrecoverable error occurred. INT PROC check^term; BEGIN INT error; CALL AWAITIO (termfnum,,termlen,,0D); ! check for completion. IF = THEN RETURN 1; ! completion.
BISYNC Centralized Multipoint Supervisor Protocol Programming Examples Example 4-20. Program Code for Poll and Select Procedures (Page 4 of 7) sbuf ':=' "FROM " -> @s; s := IF $ALPHA (source.<8:15>) THEN source.<8:15> ELSE source.<8:15> LOR %60; ! convert binary to s[1] := ":"; ! numeric. s[2] ':=' [" "] & array FOR length -> @s; ! display the message.
BISYNC Centralized Multipoint Supervisor Protocol Programming Examples Example 4-20. Program Code for Poll and Select Procedures (Page 5 of 7) BEGIN ! put select list entry number into MCW. linebuf := poll^count + array.<12:15>; ! format the message. slinebuf[2] ':=' [ DLE, STX ] -> @s; s := source.<8:15>; s[1] ':=' array FOR length & [ETX] -> @s; ! send the message. CALL WRITE (linefnum, linebuf, @s '-' @slinebuf); IF <> THEN CALL CONTROL (linefnum,13); ! clear the line. END; END; ! select.
BISYNC Centralized Multipoint Supervisor Protocol Programming Examples Example 4-20. Program Code for Poll and Select Procedures (Page 6 of 7) BEGIN IF poll THEN BEGIN ! a station responded to the ! poll. no^responder := 0; CALL select (linebuf + 1,slinebuf[5], linelen - 6); END ELSE ! no response to poll, check terminal ! for completion. IF (term^done := check^term) THEN no^responder := 0; CASE term^done OF BEGIN ! 0 ! ; ! no completion. ! 1 ! IF termlen THEN ! completion.
BISYNC Centralized Multipoint Supervisor Protocol Programming Examples Example 4-20. Program Code for Poll and Select Procedures (Page 7 of 7) ! pass the address list to Envoy. CALL DEFINELIST (linefnum,addr^list,addr^size, num^entries,poll^count,1); IF < THEN CALL DEBUG; ! start processing. CALL doit; END; ! example.
BISYNC Centralized Multipoint Supervisor Protocol Envoy Application Programming Manual—427159-001 4- 56 Programming Examples
5 BISYNC Multipoint Tributary Protocol A BISYNC centralized multipoint network Envoy consists of two or more stations communicating over a leased multidrop line with one station designated as the supervisor and the other stations designated as tributaries. This section describes the binary synchronous communication protocol used by an application process acting as a tributary station in a BISYNC centralized multipoint network. The tributary responds to poll and select sequences issued by the supervisor.
Application Process Interface BISYNC Multipoint Tributary Protocol Table 5-1.
BISYNC Multipoint Tributary Protocol Station Addresses select state active. You specify the initial states of these bits when you create the address list (prior to calling DEFINELIST). After passing the address list to Envoy, you can subsequently alter the state of these bits by calling the CHANGELIST procedure. The typical method of operation for an application process acting as a tributary station is as follows: 1.
Station Addresses BISYNC Multipoint Tributary Protocol Figure 5-1. BISYNC Multipoint Tributary Polling CALL OPEN... CALL DEFINELIST... CALL READ... 2 Concurrent Processing No Something to send ? Yes CALL CHANGELIST... Station is Polled READ Completes CALL WRITE... Nowait All Stations’ Poll/Select States set to Inactive Monitor Communication Line Stations’ Poll State set to Active (Something to send) Error = 166 (Address has been polled).
BISYNC Multipoint Tributary Protocol Station Addresses When the application process can accept data, the action is similar to an application process acting as a tributary station: 1. To indicate the ability to accept data, the application process sets the station’s select state to active by calling the CHANGELIST procedure. 2. When the station is selected, the outstanding READ completes with a no-error indication.
ASCII and EBCDIC Line Code BISYNC Multipoint Tributary Protocol Figure 5-2. BISYNC Multipoint Tributary Selection CALL CHANGELIST... Stations’ Select State Set to Active (Willing to Receive) 1 CALL READ... Monitor Communication Line Station is Selected READ Completes Error = 0, First Message in Line Buffer CALL READ... Read Data from Supervisor No Message End with EXT? Yes CALL CHANGELIST... Stations’ Select State Set to Inactive 2 CDT 036.
Timeouts BISYNC Multipoint Tributary Protocol The maximum number of times that Envoy retries an operation encountering an error indication is specified by the retry count value (RETRIES) when issuing the ADD DEVICE command. The retry count value can be altered with a call to the SETMODE procedure. If an error condition persists after the operation has been retried the specified number of times, an error indication is returned to the application process that requested the operation.
BISYNC Multipoint Tributary Protocol File-System Procedures File-System Procedures The application process uses the following Guardian 90 file-system procedures to interact with Envoy and to communicate with the supervisor station. The file-system procedures are presented in alphabetic order. AWAITIO Waits for completion of an outstanding nowait I/O operation. CHANGELIST Changes a designated station’s poll state or select state to active or inactive.
BISYNC Multipoint Tributary Protocol File-System Procedures FILEINFO Returns error information and characteristics about an open line. OPEN Establishes communications with a line. A line can be opened by only one process (and its backup) at a time. READ Monitors the line for polling and selection sequences and accepts data from the supervisor station. A call to READ while the line is in the CONTROL state (an initial READ) causes Envoy to monitor the line.
File-System Procedures BISYNC Multipoint Tributary Protocol Table 5-4. SETMODE Operations for BISYNC Multipoint Tributary Operation Parameter Description 15 1 Sets timeout duration in 10-millisecond units. 2 Sets number of times to retry. 1 Sets line type. .<14:15> 2: Specifies multipoint tributary. 16 3: Specifies multipoint supervisor.* 17 1 Specifies intermediate block size in words.
Address-List Format BISYNC Multipoint Tributary Protocol Address-List Format This subsection includes: • • • Station address on page 5-12 Poll List on page 5-12 Select List on page 5-12 The address list tells Envoy the poll and select addresses of the stations that the application process represents. The address list is passed to Envoy, after the line has been opened and before the first call to WRITE or READ, with a call to the DEFINELIST procedure.
BISYNC Multipoint Tributary Protocol Station address Station address Each entry in the address list is a station address. A station address has the following form: address-ENQ Each station address (including the ENQ character) must contain exactly the address size times two byte elements. All station addresses in a given address list are the same size. Addresses containing an odd number of bytes must be padded with a leading SYN character (%026) or a trailing NUL character (%0). (See Example 5-2.
Select List BISYNC Multipoint Tributary Protocol Example 5-2. Address List Example LITERAL addr^size = 3, ! num^entries = 6, ! ENQ = 5, ! SYN = %26, ! poll^count = 2, ! inactive = %200; ! STRING .saddr^list[ 0 : addr^size ! address list. [inactive + "A","A01", ENQ, 0, inactive + "B","B01", ENQ, 0, inactive + "a","a01", ENQ, 0, address size in words. number of address-list entries. ASCII ENQ character. ASCII SYN character. number of poll-list entries. sets stations to "inactive.
Poll and Select States BISYNC Multipoint Tributary Protocol Poll and Select States Each address in the address list has an associated poll-state or select-state bit. (The pollstate or select-state bit is in the most significant bit position of the first element of a station address, that is, station address.<0>.) The states of the poll-state and select-state bit are: 0 = active 1 = inactive In the poll list, active means that the station has data to send.
Message Formats BISYNC Multipoint Tributary Protocol The application process then sends the data that was read from the input device to the supervisor station, using one or more calls to the WRITE procedure. When the transmission to the supervisor station is completed, the application process calls the CHANGELIST procedure to set station 2’s poll state to inactive.
BISYNC Multipoint Tributary Protocol Message Formats where ms is the message size in words (message length in bytes plus one, divided by two). The form of the MCW is: MCW.<1> = READ type. The state of this bit indicates whether the READ that completed was an initial READ (that is, station just selected) or a continuation READ: 1 = initial READ 0 = continuation READ The purpose of this bit is to allow the application process to detect an aborted- transmission sequence by the supervisor station.
Normal Text BISYNC Multipoint Tributary Protocol Normal Text Normal text is indicated by messages having the following form: message = STX—text—ETB message = STX—text—ETX (message length = 2 + text length) Transparent Text Transparent text is indicated by messages having the following form: message = DLE STX—text—ETB message = DLE STX—text—ETX (message length = 3 + text length) Transparent mode is initiated by inserting a DLE control character before the STX.
BISYNC Multipoint Tributary Protocol Normal Text With ITBs No Need for Line Turnaround Intermediate text blocking allows individual (or intermediate) blocks to be checked for errors and then another block to be sent immediately without the need for line turnaround (that is, without the receiver acknowledging each block) as is the case with normal blocking.
File-System Errors BISYNC Multipoint Tributary Protocol Upon receipt of transparent text, if intermediate text blocking is indicated, Envoy deletes ITB characters occurring at the end of each intermediate block (the length of each block received must be the same as the specified intermediate block length). File-System Errors Upon completion of a file-system request, the multipoint tributary application process should check for the Guardian 90 file-system error codes shown in Table 5-7. Table 5-7.
BISYNC Multipoint Tributary Protocol Line Action by Procedure Call Line Action by Procedure Call This subsection describes the BISYNC control sequences transmitted because of calls to file-system procedures. It also describes the actions of file-system procedures in response to line states and the reception of selected control sequences.
READ Procedure BISYNC Multipoint Tributary Protocol Example 5-3. Initial READ (Line in CONTROL Inactive State) Tributary (Local) Supervisor (Remote) line state = CONTROL all select addresses = inactive CALL READ(...) | <-- EOT SYN-poll addr | EOT --> | <-- EOT SYN-poll addr | EOT --> | poll address 1 set active using CHANGELIST | | <-- EOT SYN-poll addr (Initial READ completes) error = 166 line state = WRITE MCW.
READ Procedure BISYNC Multipoint Tributary Protocol Example 5-4. Initial READ (Line in CONTROL Active State) Tributary (Local) Supervisor (Remote) line state = CONTROL all select addresses = inactive CALL READ(...) | <-- EOT SYN-sel addr 1-ENQ | RVI --> | <-- EOT SYN-sel addr 2-ENQ | RVI --> | sel address 1 set active using CHANGELIST | | <-- EOT SYN-sel addr 1-ENQ | ACK0 --> | <-- message 1 (READ completes) error = 0 line state = READ MCW.<1> = 1 (READ type = initial READ) MCW.
READ Procedure BISYNC Multipoint Tributary Protocol Table 5-9. Initial READ File System Errors (page 2 of 2) Error State Description Resultant Line Number 177 Text overrun. The length of the message received exceeds the length specified in the read count parameter. The READ was attempted the number of times specified by the retry value. CONTROL 178 No address list was specified. CONTROL Continuation READ (Line in READ State) All READs following the initial one are continuation READs.
READ Procedure BISYNC Multipoint Tributary Protocol Table 5-10. Continuation READ File-System Errors Error State Description Resultant Line Number 0 No error. The message is returned to application process’s buffer. READ 60 Request is invalid for line state. unknown 161 Impossible event occurred for line state. unknown 162 Operation timed out. The acknowledgment was sent but no message was received within the timeout or retry limits. CONTROL 172 Reply not proper for protocol.
READ-Type Bit BISYNC Multipoint Tributary Protocol READ-Type Bit The READ-type bit allows the application process to detect an aborted transmission sequence from the supervisor station. The READ-type bit is located in MCW.1 (message control word, bit 1).
WRITE Procedure BISYNC Multipoint Tributary Protocol WRITE Procedure The WRITE procedure is used by a polled tributary station to transmit messages to the supervisor station. While messages are being sent, the line is in a WRITE state. The line returns to the CONTROL state when the tributary station sends an EOT sequence (to indicate the completion of the transmission).
BISYNC Multipoint Tributary Protocol WRITEREAD Procedure (Conversational Exchange) Table 5-11. Continuation WRITE File-System Errors (page 2 of 2) Error State Description Resultant Line State 165 RVI received. The tributary transmitted a reverse interrupt sequence as a positive acknowledgment. WRITE 166 ENQ in response to message. WRITE 171 No response to selection. The selection was attempted the number of times specified by the retry value. WRITE 172 Reply not proper for protocol.
CONTROL Procedure (Send EOT) BISYNC Multipoint Tributary Protocol Example 5-9. Possible Line States After Continuation WRITEREAD Tributary (Local) Supervisor (Remote) line state = WRITE CALL WRITEREAD (...) | message n --> | | <-- ACKn or (WRITE completes) message 1 If ACKn received, line state = WRITE. If message received, line state = READ. The file-system errors for a continuation WRITEREAD are the same as those for a continuation WRITE.
CONTROL Procedure (Send WACK) BISYNC Multipoint Tributary Protocol CONTROL Procedure (Send WACK) The WACK sequence is used following a READ to delay the acknowledgment to the supervisor while maintaining the communications link. The application sends WACK by calling the CONTROL procedure and specifying operation 14 (Example 5-11). Example 5-11.
Initial READ Operation BISYNC Multipoint Tributary Protocol Figure 5-3. BISYNC Multipoint Tributary Initial READ CALL READ...
BISYNC Multipoint Tributary Protocol Continuation READ Operation Table 5-12 lists the error codes that can occur during an initial READ operation. Table 5-12. Initial READ Error Codes Error Code Description 161 Impossible state 166 Address was polled 172 Reply not proper for protocol 173 Transmission error 177 Text overrun Continuation READ Operation Figure 5-4 shows the action of the tributary station in response to line conditions on a continuation READ.
Continuation READ Operation BISYNC Multipoint Tributary Protocol Figure 5-4. BISYNC Multipoint Tributary Continuation READ CALL READ...
BISYNC Multipoint Tributary Protocol Continuation READ Operation Table 5-13 lists the error codes that can occur during an continuation READ operation. Table 5-13. Continuation READ Error Codes Error Code Description 162 Operation timed out 172 Reply not proper for protocol 173 Transmission error 177 Text overrun All WRITEs by a tributary station are continuation WRITEs. Figure 5-5 shows a continuation WRITE.
Continuation READ Operation BISYNC Multipoint Tributary Protocol Figure 5-5. BISYNC Multipoint Tributary Continuation WRITE CALL WRITE...
BISYNC Multipoint Tributary Protocol Programming Examples Table 5-14. Continuation WRITE Error Codes Error Code Description 172 Reply not proper for protocol 173 Transmission error 175 Incorrect ACK received 177 Text overrun Programming Examples The examples in the next pages show the following operations: • • Polling of a tributary and sending messages to the supervisor Selecting of a tributary and reading messages from the supervisor Both operations are shown in the same example program.
Programming Examples BISYNC Multipoint Tributary Protocol Figure 5-6 shows the station addresses that the tributary program represents in the multipoint network. Figure 5-6. BISYNC Multipoint Tributary Station Addresses Tributaries Supervisor S 0 Poll Address = PA Select Address = Sa 1 2 3 CDT 040.
Programming Examples BISYNC Multipoint Tributary Protocol Figure 5-7 shows the flow of the polling and selecting operation. Figure 5-7.
Programming Examples BISYNC Multipoint Tributary Protocol Example 5-13 shows the control sequences that take place when the station is polled and sends a message to the supervisor station. Example 5-13.
Programming Examples BISYNC Multipoint Tributary Protocol Example 5-14 shows the control sequences that take place when the station is selected and receives a message from the supervisor station. Example 5-14. Selected Tributary Receives a Message Tributary (Local) poll state = inactive select state = active CALL READ | | | ACK0 --> | (READ completes) error = 0 line state = READ MCW.
Programming Examples BISYNC Multipoint Tributary Protocol Example 5-15. Program Code for BISYNC Multipoint Tributary (Page 1 of 7) ?LMAP* ! line buffer message format (transparent text) ! ! byte ! [0] [2] [3] [4] [5] [7] ! MCW DLE STX ,--ETX ! ! MCW = message control word ! ! s = source station identity, one byte: S = supervisor, ! 0:3 = tributary ! d = destination station identity. ! INT termfnum, .
BISYNC Multipoint Tributary Protocol Programming Examples Example 5-15. Program Code for BISYNC Multipoint Tributary (Page 2 of 7) STRING .saddr^list[ 0 : addr^size * num^entries * 2 - 1] := [no^poll + "P","A", ENQ, 0, ! entry 0, station 0 poll. "Sa", ENQ, 0]; ! entry 1, station 0 select. INT .addr^list := @saddr^list ’>>’ 1; ?NOLIST ?SOURCE $SYSTEM.SYSTEM.
BISYNC Multipoint Tributary Protocol Programming Examples Example 5-15. Program Code for BISYNC Multipoint Tributary (Page 3 of 7) INT PROC check^term; BEGIN INT error; CALL AWAITIO (termfnum,,termlen,,0D); ! ! IF = THEN RETURN 1; ! IF > THEN RETURN 2; ! ! else error. CALL FILEINFO (termfnum,error); IF error = 40 THEN RETURN 0; ! RETURN IF FILEERROR (termfnum) THEN 3 ! ELSE 4; ! END; ! check^term. check for completion. completion. end of file. no completion. retry. fatal error.
BISYNC Multipoint Tributary Protocol Programming Examples Example 5-15. Program Code for BISYNC Multipoint Tributary (Page 4 of 7) sbuf ’:=’ "FROM " -> @s; s := IF $ALPHA (source.<8:15>) THEN source.<8:15> ELSE source.<8:15> LOR %60; ! convert binary to ! ASCII. s[1] := ":"; s[2] ’:=’ [" "] & array FOR length -> @s; ! display the message.
BISYNC Multipoint Tributary Protocol Programming Examples Example 5-15. Program Code for BISYNC Multipoint Tributary (Page 5 of 7) ! format the message. linebuf := 0; slinebuf[2] ’:=’ [ DLE, STX, 0 ] -> @s; s ’:=’ array FOR length & [ETX] -> @s; ! send the message. CALL WRITE (linefnum, linebuf, @s ’-’ @slinebuf); CALL AWAITIO (linefnum); IF = THEN ! done, so set poll inactive. CALL CHANGELIST (linefnum, 0,1); END; ! send.
BISYNC Multipoint Tributary Protocol Programming Examples Example 5-15. Program Code for BISYNC Multipoint Tributary (Page 6 of 7) ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Then the line is checked for a completion. If the completion indicates the line was polled, the message is sent to the supervisor (polling is indicated only if the station’s poll state is "active," which happens only if the station has something to send).
BISYNC Multipoint Tributary Protocol Programming Examples Example 5-15. Program Code for BISYNC Multipoint Tributary (Page 7 of 7) ! 2 ! done := 1; ! end-of-file. ! 3 ! ; ! retry. ! 4 ! CALL ABEND; ! fatal error. END; CASE (line^done := check^line) OF BEGIN ! 0 ! ; ! no completion. ! 1 ! BEGIN ! selected. CALL CANCEL (termfnum); IF = THEN term^done := 2; CALL write^term (slinebuf[4], slinebuf[7], linelen - 8); END; ! 2 ! BEGIN ! polled. CALL send (termbuf,termlen); term^done := 2; END; ! 3 ! ; ! error.
6 Full-Duplex Protocol The Envoy full-duplex protocol is a program-design tool that enables you to develop your own byte-synchronous full-duplex line protocol at the application level.
Half-Duplex and Full-Duplex Lines Full-Duplex Protocol To receive a message, the application process calls the READ procedure. The Envoy full-duplex protocol allows multiple read buffers to be defined when issuing the ADD DEVICE command. Each READ call obtains the content of the next successive input buffer. Messages are discarded when they have errors or when no buffer is available. The protocol implemented by your application process must be able to detect missing messages.
Full-Duplex/NASDAQ Line Requirements Full-Duplex Protocol Figure 6-2. Full-Duplex Lines Send Receive CDT 009.CDD Communications pass over a full-duplex line like two-way traffic passes over a divided highway. A full-duplex line enables a station to send messages and receive messages at the same time. Although full-duplex line facilities are more expensive than half-duplex facilities, the additional cost usually is offset by the decreased response time and increased throughput over the line.
Full-Duplex/NASDAQ Line Requirements Full-Duplex Protocol • • When you configure an Envoy DEVICE that is type (7,30) or type (7,32) you must specify UNIT 0. UNIT 0 indicates outgoing (write) line. When you configure an Envoy DEVICE that is type (7,31) or type (7,33) you must specify UNIT 1. UNIT 1 indicates incoming (read) line.
File-System Procedures Full-Duplex Protocol When you stop one of the multi devices (for example, $ZZWAN.#LINE 1), the other multi device also stops. Similarly, if you stop one of the LINE objects (for example, $LINE1), the other LINE object also stops. If you issue an SCF STATUS SERVER command on the SWAN concentrator to see the name of the line using a particular line, only the first DEVICE that was configured will be shown.
Message Formats Full-Duplex Protocol OPEN Enables access to a communications line. READ Accepts incoming messages received from the remote station. SETMODE Alters the line characteristics (Table 6-2). Table 6-2. SETMODE Operations for Full-Duplex Operation Parameter Description 15 1 Specifies timeout duration in 10 millisecond units. 16 1.<3> 0: Disables application’s ability to receive control characters. 1: Enables application to receive control characters.
Normal Text Full-Duplex Protocol The following types of message formats are allowed: • • • Normal Text on page 6-7 Transparent Text on page 6-7 Headings on page 6-7 Normal Text Normal text is indicated by messages having the following form: message = STX—text—ETB message = STX—text—ETX (message length = 2 + text length) Transparent Text Transparent text is indicated by messages having the following form: message = DLE STX—text—ETB message = DLE STX—text—ETX (message length = 3 + text length) Envoy aut
File-System Errors Full-Duplex Protocol File-System Errors Upon completion of a file-system request, the Compaq application process should check for the Guardian 90 file-system error codes listed in Table 6-4. Table 6-4.
7 ADM-2 Multipoint Supervisor Protocol The ADM-2 multipoint supervisor protocol enables an application process to act as the supervisor station in a centralized multipoint network consisting of either of the following terminals: • • Lear-Siegler ADM-2 Interactive Display Terminals with the polling option installed or Burroughs terminals that can interface with the Burroughs Basic Poll/Select protocol Topics discussed in this section include: • • • • • • • • • Protocol Capabilities on page 7-1 Applicati
Application Process Interface ADM-2 Multipoint Supervisor Protocol Table 7-1. ADM-2 Multipoint Format ADM-2 Multipoint Format Individual poll EOT a1 a1 p ENQ Individual select EOT a1 a1 q ENQ Sequential select EOT a1 a1 ra2 a2 r...an an s STX-text-ETX LRC Broadcast select EOT a1 a1 ra2 a2 t...
ADM-2 Multipoint Supervisor Polling ADM-2 Multipoint Supervisor Protocol ADM-2 Multipoint Supervisor Polling The application initiates polling by calling the READ procedure while the line is in the CONTROL state. This call also reads the message from the responding terminal. Figure 7-1 shows ADM-2 multipoint supervisor polling. Figure 7-1. ADM-2 Multipoint Supervisor Polling CALL OPEN... nowait CALL DEFINELIST... 2 CALL READ...
ADM-2 Multipoint Supervisor Selection ADM-2 Multipoint Supervisor Protocol ADM-2 Multipoint Supervisor Selection The supervisor selects a terminal and passes text to it by calling the WRITE procedure. Figure 7-2 shows ADM-2 multipoint supervisor selection. Figure 7-2. ADM-2 Multipoint Supervisor Selection 1 Format Message CALL WRITE... 2 Send Data to Terminal CDT 043.
ADM-2 Multipoint Supervisor Protocol File-System Procedures Table 7-2. Effect of the Timeout Value Protocol State Effect of Timeout Value During WRITE Determines the period of time following the selection of a terminal that Envoy waits for an acknowledgment. During READ Determines how long Envoy waits for an acknowledgment from a polled terminal. An operation that times out is retried the maximum of times specified by the retry count before an error indication is returned to the application process.
File-System Procedures ADM-2 Multipoint Supervisor Protocol . Table 7-3. CONTROL Operations for ADM-2 Operation Parameter 13 1 .<0> Description 0: Sends EOT (used to clear the network after an error occurs) 1: Performs specific poll on device indicated by station index value. .<8:15> = n Specifies station index value of station to be polled. DEFINELIST Passes the poll and select address list to Envoy. The format of the address list is described under Address-List Format on page 7-8.
File-System Procedures ADM-2 Multipoint Supervisor Protocol message control word to the application’s line buffer to indicate which terminal responded. A call to READ while the line is in the READ state (a continuation READ) causes Envoy to acknowledge the preceding message with the proper ACK sequence, accept the EOT indication from the terminal, and resume polling of the network. SETMODE Alters the line characteristics shown in Table 7-4. Table 7-4.
ADM-2 Multipoint Supervisor Protocol Address-List Format Note. For a complete list of SETMODE procedures supported by the Envoy protocols, see the SETMODE procedure description in Table C-5 on page C-27, which also lists the analogous modifier for these procedures. WRITE Transmits data to a terminal.
Terminal Address ADM-2 Multipoint Supervisor Protocol Example 7-1. Address List terminal address, entry 0 terminal address, entry 0 . . . terminal address, entry pn-1 terminal address, entry pn terminal address, entry pn+1 . . .
Polling ADM-2 Multipoint Supervisor Protocol Example 7-2. Build an Address List LITERAL addr^size = 3, num^entries = 6, NULL EOT ENQ poll^count = = = = 0, 4, 5, 3; ! address size in words. ! number of address-list !entries. ! ASCII NULL character. ! ASCII EOT character. ! ASCII ENQ character. ! number of poll-list entries. STRING .saddr^list[ 0 : addr^size * num^entries * ! address list.
Polling Type ADM-2 Multipoint Supervisor Protocol • Nonresponding Terminal List on page 7-17 Polling Type The ADM-2 multipoint supervisor protocol supports the following types of polling: • • • Continuous Polling on page 7-11 Noncontinuous Polling on page 7-12 Specific Polling on page 7-14 Continuous Polling Continuous polling occurs indefinitely until a terminal responds to the poll with text or an error occurs.
ADM-2 Multipoint Supervisor Protocol Polling Type If a polled station responds with text, the READ completes with the line in the READ state and an error 0 (operation successful). Along with the text message, the polled station returns a message control word (MCW), which contains the polled station’s entry number, to the line buffer of the application process.
Polling Type ADM-2 Multipoint Supervisor Protocol Figure 7-4. ADM-2 Multipoint Supervisor Noncontinuous Poll Sequence CALL OPEN... CALL DEFINELIST... CALL READ... Poll Count = (Polling Type) from DEFINELIST Poll Entry 0 EOT Poll Entry 1 EOT Poll Entry pn-1 EOT Poll Count = Poll Count - 1 No Poll Count = 0? Yes Error = 176 CDT 045.CDD The Example 7-4 shows how to change a line’s polling type from continuous to noncontinuous: Example 7-4.
ADM-2 Multipoint Supervisor Protocol Polling Type Each terminal is polled a maximum of ten times for each call to the READ procedure when the line is in the CONTROL state (if polling is currently in progress, the change does not take effect until the next call to READ). Specific Polling Specific polling occurs when a designated terminal is polled once. The polling of only one specified terminal is designated with a call to the CONTROL procedure.
Polling Interval ADM-2 Multipoint Supervisor Protocol Polling Interval The polling interval specifies a time interval that Envoy waits, following a pass through the poll list, before beginning a subsequent pass through the poll list. Figure 7-5 shows the use of the polling interval. The polling interval is specified for a communications line when issuing the ADD DEVICE command and can be altered with a call to the SETMODE procedure.
Poll State ADM-2 Multipoint Supervisor Protocol Poll State Each address in the poll list has an associated poll-state bit. The poll-state bit is in the most significant bit position of the first element of a station address; that is, station address.<0.> Table 7-5 shows the meaning of the poll-state bit setting. Table 7-5.
ADM-2 Multipoint Supervisor Protocol Nonresponding Terminal List Example 7-6. Disable Polling for a Specific Terminal LITERAL addr^size = 3, ! address size in words. num^entries = 6, ! number of address-list !entries. NULL = 0, ! ASCII NULL character. EOT = 4, ! ASCII EOT character. ENQ = 5, ! ASCII ENQ character. poll^count = 3, ! number of poll-list entries. no^poll = %200; ! used to set poll-state bit. STRING .saddr^list[ 0 : addr^size * num^entries * ! address list.
Message Formats ADM-2 Multipoint Supervisor Protocol • • Defining a new poll list to Envoy with the DEFINELIST procedure or Calling the CHANGELIST procedure and specifying that all terminals are to be removed from the nonresponding list. Note that if a terminal’s poll state is set to "disable polling," it is not be polled. The Example 7-7 shows how to remove terminals from the nonresponding list: Example 7-7. Remove Terminals From Nonresponding List CALL CHANGELIST (linefnum, -2, 0); IF < THEN ...
ADM-2 Multipoint Supervisor Protocol Message Formats terminal to behave in the same manner as a special message formatted by Envoy. MCW.<6> = message type 0 = normal message 1 = special message (fast-select, broadcast-select, and sequential-select) MCW.<8:15>= entry number. This is a value that indicates an entry in the address list.
ADM-2 Multipoint Supervisor Protocol Normal Text The ADM-2 multipoint supervisor protocol accepts the following types of message formats: • • • • • Normal Text on page 7-20 Sequential Select on page 7-20 Fast Select on page 7-21 Broadcast Select on page 7-22 Send Function on page 7-23 Normal Text Normal text is indicated by messages of the form: message = STX-text-ETX (message length = 2 + text length) The following message format is received by the application process if the terminal operation presse
Fast Select ADM-2 Multipoint Supervisor Protocol If the application process inserts the terminal addresses, then the message is passed to Envoy (using the WRITE procedure) as shown above. In that case: MCW.<5> = 1 (message formatted by the application process) (message length = 5 + number of terminals * 3 + text length) If Envoy is to insert the terminal addresses, then the message is passed to Envoy (with the WRITE procedure) in the following form: MCW.
Broadcast Select ADM-2 Multipoint Supervisor Protocol If Envoy is to insert the terminal address, the message is passed to Envoy (with the WRITE procedure) in the following form: MCW.
Send Function ADM-2 Multipoint Supervisor Protocol t is a one-byte broadcast-select function code entry no 1 is the one-byte address-list entry number of the first terminal to receive the message entry no 2 is the one-byte address-list entry number of the second terminal to receive the message entry no n is the one-byte address-list entry number of the last terminal to receive the message 0 is a one-byte place holder s is a one-byte fast-select function code (message length = 5 + number of ter
ADM-2 Multipoint Supervisor Protocol File-System Errors If Envoy is to insert the terminal addresses, then the message is passed to Envoy (with the WRITEREAD procedure) in the following form: MCW.
ADM-2 Multipoint Supervisor Protocol Line Action by Procedure Call General file-system errors (Table 7-7) are also possible. Table 7-7. General File-System Errors Error Code Description 10-29 Coding or access problem 30-33 System configuration problem 120-199 Device hardware problem 200-255 Path error Line Action by Procedure Call This subsection describes the ADM-2 control sequences transmitted because of calls to file-system procedures.
READ Procedure ADM-2 Multipoint Supervisor Protocol Example 7-9. Initial READ (Line in CONTROL State) Application Process Terminal line state = CONTROL CALL READ(...) | EOT a1 | | EOT a2 | | | | EOT an | (READ completes) error = 0 line state = READ MCW.<8:15> contains a1 p ENQ --> <-- EOT a2 p ENQ --> . . . an p ENQ --> <-- EOT . . . message entry number for station "n" Note. The message from the terminal is not acknowledged by the initial READ.
READ Procedure ADM-2 Multipoint Supervisor Protocol Table 7-8. Initial READ File-System Errors (page 2 of 2) Error Numbers Description Resultant Line Number 176 Poll sequence ended with no responder. The specified number of passes have been made through the poll list and no message has been received. This error may also indicate that an empty poll list was specified. CONTROL 177 Text overrun. The length of the message received exceeds the length specified in the read count parameter.
WRITE Procedure ADM-2 Multipoint Supervisor Protocol Table 7-9 lists file-system errors that may occur on a continuation READ. Table 7-9. Continuation READ File-System Errors Error Numbers Description Resultant Line Number 160 Request is invalid for device state; protocol error. unknown 161 Impossible event occurred for line state. unknown 162 Operation timed out. The acknowledgment was sent but no message was received within the timeout or retry limits. CONTROL 163 EOT received.
WRITE Procedure ADM-2 Multipoint Supervisor Protocol Example 7-11. WRITE of Normal Text Message (Line in CONTROL State) Application Process Terminal line state = CONTROL MCW.<6> = 0 (message type = normal) CALL WRITE(..
WRITE Procedure ADM-2 Multipoint Supervisor Protocol The call to the WRITE procedure completes when the terminal acknowledges the message. The successful transmission of the message is indicated by a condition code of CCE upon completion of the WRITE. Example 7-13. WRITE of Normal Text Message (Line in READ State) Application Process Terminal line state = READ MCW.<6> = 0 (message type = normal) CALL WRITE(...
ADM-2 Multipoint Supervisor Protocol WRITEREAD Procedure (Transmit a Send Function) Table 7-10 lists the file-system errors that can occur on a WRITE. Table 7-10. WRITE File-System Errors Error Numbers Description Resultant Line State 0 No error. A terminal was selected and the message in the buffer of the application process is written to it. READ 160 Request is invalid for device state; protocol error. unknown 161 Impossible event occurred for line state. unknown 162 Timeout on selection.
ADM-2 Multipoint Supervisor Protocol WRITEREAD Procedure (Transmit a Send Function) Example 7-15. WRITEREAD Procedure (Line in CONTROL State) Application Process Terminal line state = CONTROL MCW.<6> = 1 (message type = special) CALL WRITEREAD (...) | EOT a1 a1 sf ENQ --> | <-- message or EOT (WRITEREAD completes) If message received, then line state = READ, error = 0. If EOT received, then line state = CONTROL, error = 172.
ADM-2 Multipoint Supervisor Protocol Line-Error Handling CONTROL Procedure (Send EOT) Send EOT is used to reset the line following a READ error. The application sends the EOT sequence by calling the CONTROL procedure and specifying operation 13 (Example 7-17). Example 7-17.
Initial READ Operation ADM-2 Multipoint Supervisor Protocol Figure 7-6. ADM-2 Multipoint Supervisor Initial READ CALL READ... 1 Send Poll Address Wait for Response Timeout? Yes Error = 171 No Text with Error? Yes Retry Count = 0? Yes Error = 173 No No EOT Received? Send NAK Yes No List Done ? Yes No Continuous Polling? Yes Delay for Polling No No Poll Done? Yes Error = 176 Text Overrun? Yes Error = 177 No Proper Protocol ? No Error = 172 Yes Text Received? Yes Error = 0 CDT 047.
Initial READ Operation ADM-2 Multipoint Supervisor Protocol Table 7-11 lists the error codes that can occur during a initial READ operation. Table 7-11. Initial READ Error Codes Error Code Description 171 No response to poll 172 Reply not proper for protocol 173 Transmission error 176 Poll sequence ended with no responder 177 Text overrun Continuation READ Operation Figure 7-7 shows the action of the supervisor station in response to line conditions on a continuation READ. Figure 7-7.
ADM-2 Multipoint Supervisor Protocol WRITE Operation Table 7-12 lists the error codes that can occur during a continuation READ operation. Table 7-12. Continuation READ Error Codes Error Code Description 162 Operation timed out 172 Reply not proper for protocol 173 Transmission error 177 Text overrun WRITE Operation Figure 7-8 shows the action of the supervisor station in response to line conditions on a WRITE.
WRITE Operation ADM-2 Multipoint Supervisor Protocol Figure 7-8. ADM-2 Multipoint Supervisor WRITE CALL WRITE...
ADM-2 Multipoint Supervisor Protocol Programming Examples Table 7-13 lists the error codes that can occur during a WRITE operation. Table 7-13.
Programming Examples ADM-2 Multipoint Supervisor Protocol Example 7-18 shows the declarations used in the programming examples: Example 7-18. Declarations Used in the Programming Examples INT .linename[0:11], linefnum, line^count^read, line^write^count, .linebuf[-1:999]; ! ! ! ! ! name of communication line. file number of communication line. number of bytes read. number of bytes to write. line buffer. STRING .
Poll and READ Operation ADM-2 Multipoint Supervisor Protocol Poll and READ Operation Figure 7-9 shows the sequence involved in polling the network and reading a message from a terminal. Figure 7-9.
Poll and READ Operation ADM-2 Multipoint Supervisor Protocol Example 7-19 shows the line-control sequence and the program coding to poll the line and read a message from terminal 2. Example 7-19. Poll the Line and Read a Message from the Terminal Application Process line state = CONTROL CALL READ(...) | EOT 11p | | EOT 22p | | EOT 33p | . | . | . | EOT 22p | (READ completes) error = 0 line state = READ MCW.<8:15> = 1 Terminal ENQ -> <- EOT ENQ -> <- EOT ENQ -> <- EOT . . ENQ -> .
Select and Send Operation ADM-2 Multipoint Supervisor Protocol Select and Send Operation Example 7-20 demonstrates the line-control sequence and program coding to select a terminal and send a normal message to it. In this example, a message is sent to terminal 2. Example 7-20. Select and Send Operation Application Process Terminal 2 line state = READ MCW.<6> = 0 (message type = normal) MCW.<8:15> = 4 (address list entry 4, terminal 2 select) CALL WRITE(..
ADM-2 Multipoint Supervisor Protocol Sending a Broadcast-Select Message Sending a Broadcast-Select Message Example 7-21 shows the line-control sequence to send a broadcast-select message formatted by Envoy to all terminals in the network. Example 7-21. Send a Broadcast-Select Message Application Process Network line state = CONTROL MCW.<6> = 1 (message type = special) MCW.<5> = 0 (message formatter = Envoy) MCW.<8:15> = 0 (clear entry number) CALL WRITE(..
ADM-2 Multipoint Supervisor Protocol Sending a Broadcast-Select Message Example 7-22 shows the program coding for the broadcast-select operation shown in Example 7-21. Example 7-22. Program Code for a Broadcast-Select Message PROC broadcast (message, length); STRING .message; ! message to be sent. INT length; ! message length. BEGIN INT count; STRING .s; ! clear message control word. mcw := 0; ! set message type = special. mcw.<6> := 1; ! format message.
ADM-2 Multipoint Supervisor Protocol Sending a Fast-Select Message Sending a Fast-Select Message Example 7-23 shows the line-control sequence to send a fast-select message formatted by the application process to a terminal. In this example, a message is sent to terminal 3. Example 7-23. Send a Fast-Select Message Application Process Terminal 3 line state = CONTROL MCW.<6> = 1 (message type = special) MCW.<5> = 1 (message formatter = application process) MCW.<8:15> = 0 (clear entry number) CALL WRITE(...
ADM-2 Multipoint Supervisor Protocol WRITEREAD (Send Function and Read Message) Example 7-24 shows the program coding for the fast-select operation sequences shown in Example 7-23. Example 7-24. Program Code for a Fast-Select Message PROC fast^select (message, length, terminal); STRING .message; ! message to be sent. INT length, ! message length. terminal; ! terminal address in ASCII. BEGIN STRING .s; ! clear message control word. mcw := 0; ! set message type = special. mcw.
ADM-2 Multipoint Supervisor Protocol WRITEREAD (Send Function and Read Message) Example 7-25 shows the line-control sequences that take place when a function key is pressed on terminal 1, the terminal is polled, and a send function of "send page foreground" is issued to the terminal. Example 7-25. Send Function and Read Message Application Process CALL READ(...) | | EOT 11p ENQ -> | (READ completes) error = 0 line state = READ MCW.<8:15> = 0 MCW.<6> = 1 (message type = special) CALL WRITEREAD (...
ADM-2 Multipoint Supervisor Protocol WRITEREAD (Send Function and Read Message) Example 7-26 shows the program coding for the Send Function and Read Message operation shown in Example 7-25. Example 7-26. Program Code for Send Function and Read Message ! poll the network. CALL READ (linefnum,linebuf[-1], 5, line^count^read); IF = AND slinebuf = SOH THEN ! terminal responded to poll. BEGIN ! format the send function. slinebuf ’:=’ [ EOT ] & "w" - @s; ! send page foreground ! function. s := mcw.
8 TINET Multipoint Supervisor Protocol The TINET multipoint supervisor protocol enables an application process to act as the supervisor station in a centralized multipoint network consisting of Texas Instruments Numeric Entry Terminals (TINET).
Application Process Interface TINET Multipoint Supervisor Protocol Table 8-1. TINET Multipoint Supervisor Formats TINET Multipoint Supervisor Format Poll terminal EOT idp idp = terminal polling address Read data STX id aid seq {oc -data-}...ETX LRC id aid seq oc Write data (nontutorial) EOT ids STX id seq cc wcc {oc [lc ]-data-}...
TINET Multipoint Supervisor Polling TINET Multipoint Supervisor Protocol TINET Multipoint Supervisor Polling The supervisor polls the terminals and accepts messages by calling the READ procedure. Figure 8-1 shows the TINET multipoint supervisor polling sequence. Figure 8-1. TINET Multipoint Supervisor Polling CALL OPEN... nowait CALL DEFINELIST... 2 CALL READ...
TINET Multipoint Supervisor Selection TINET Multipoint Supervisor Protocol TINET Multipoint Supervisor Selection The supervisor station selects a terminal by calling the WRITE procedure. The call also writes the message to the selected terminal. Figure 8-2 shows the TINET multipoint supervisor selection sequence. Figure 8-2. TINET Multipoint Supervisor Selection 1 Format Message CALL WRITE... 2 Send Data to Terminal CDT 043.
TINET Multipoint Supervisor Protocol File-System Procedures Table 8-2.
TINET Multipoint Supervisor Protocol File-System Procedures Table 8-3. CONTROL Operations for TINET (page 2 of 2) Operation Description 15 Sends CAN. A cancel (CAN) code is sent to the transmitting terminal in response to an error 173 (maximum allowable NAKs received) on a READ. The receipt of the CAN by the terminal causes the terminal to retain the data just entered. The terminal sends the data the next time it is polled. DEFINELIST Passes the poll and select address list to Envoy.
Address-List Format TINET Multipoint Supervisor Protocol SETMODE Alters the line characteristics shown in Table 8-4. Table 8-4. SETMODE Operations for TINET Operation Parameter Description 15 1 Sets timeout duration in 10-millisecond units 2 Sets number of times to retry 1 Sets line type 2 Sets polling interval in 10-millisecond units 17 1 Sets intermediate block size in words 18 1 Sets statistics threshold 16 Note.
Station Address TINET Multipoint Supervisor Protocol Station Address An address list consists of a poll list followed by a select list (Example 8-1). Example 8-1. Address List EOT EOT idp, entry 0 ENQ EOT EOT idp, entry 0 ENQ . . . EOT EOT idp, entry pn-1 ENQ EOT ids, entry pn NUL NUL EOT ids, entry pn+1 NUL NUL . . .
Polling TINET Multipoint Supervisor Protocol Example 8-2. Build an Address List LITERAL addr^size = 2, num^entries = 6, NUL EOT ENQ poll^count poll^type = = = = = 0, 4, 5, 3, 0; ! ! ! ! ! ! ! ! address size in words. number of address-list entries. ASCII NULL character. ASCII EOT character. ASCII ENQ character. number of poll-list entries. specifies continuous polling. STRING .saddr^list[ 0 : addr^size * num^entries ! address list.
TINET Multipoint Supervisor Protocol Polling Type Polling Type The TINET Multipoint Supervisor protocol supports the following types of polling: • • • Continuous Polling on page 8-10 Noncontinuous Polling on page 8-12 Specific Polling on page 8-14 Continuous Polling Continuous polling occurs indefinitely until a terminal responds to the poll with text, or an error occurs.
Polling Type TINET Multipoint Supervisor Protocol Figure 8-3 shows the TINET multipoint supervisor continuous poll sequence. Figure 8-3. TINET Multipoint Supervisor Continuous Poll CALL OPEN... CALL DEFINELIST... CALL READ... Poll List Entry 0 EOT Poll List Entry 1 EOT Poll List Entry pn-1 EOT CDT 044.CDD If a polled station responds with text, the READ completes with the line in the READ state and an error 0 (operation successful).
TINET Multipoint Supervisor Protocol Polling Type The READ completes either when a terminal responds to the poll with a message or when a line error is detected. If a terminal responds with a message, the entry number of the terminal in the poll list is returned in linebuf.8:15 (for more information, see Message Formats on page 8-18). The message is also returned in linebuf, and a condition code of CCE is given.
Polling Type TINET Multipoint Supervisor Protocol Figure 8-4. TINET Multipoint Supervisor Noncontinuous Poll CALL OPEN... CALL DEFINELIST... CALL READ... Poll Count = (Polling Type) from DEFINELIST Poll Entry 0 EOT Poll Entry 1 EOT Poll Entry pn-1 EOT Poll Count = Poll Count - 1 No Poll Count = 0? Yes Error = 176 CDT 045.CDD Example 8-4 shows how to change a line’s polling type from continuous to noncontinuous: Example 8-4.
TINET Multipoint Supervisor Protocol Polling Type The supervisor polls each station in the network a maximum of ten times for each call to the READ procedure when the line is in the CONTROL state. If polling is currently in progress, the change does not take effect until the next call to READ from the CONTROL state. Specific Polling Specific polling causes a designated terminal to be polled once. The polling of only one specified terminal is designated with a call to the CONTROL procedure.
Polling Interval TINET Multipoint Supervisor Protocol Polling Interval The polling interval specifies a time interval that Envoy waits, following a pass through the poll list, before beginning a subsequent pass through the poll list. Figure 8-5 shows the use of the polling interval. The polling interval is specified for a communications line when issuing the ADD DEVICE command. You can alter the polling interval by calling the SETMODE procedure.
Poll State TINET Multipoint Supervisor Protocol Poll State Associated with each address in the poll list is a poll state bit. (The poll state bit is in the most-significant bit position of the first element of each entry in the poll list).
TINET Multipoint Supervisor Protocol Nonresponding Terminal List In the example above, terminal 2 (%041) is not polled when polling is initiated. Selective Polling (After Calling DEFINELIST) Example 8-7 shows how to enable polling for a specific terminal by means of a call to the CHANGELIST procedure. The terminal to be enabled for polling is terminal %041 in the above example. Example 8-7.
Message Formats TINET Multipoint Supervisor Protocol Note. If the nonresponding terminal list becomes full (no stations responding), subsequent calls to READ result in error 176 (poll sequence ended with no responder). Therefore, a new list must be defined or all stations must be removed from the nonresponding list. Message Formats A message is defined as the information transmitted over a communication line as a result of a single call to a READ or a WRITE procedure.
Read Message TINET Multipoint Supervisor Protocol The TINET multipoint supervisor protocol supports the following message formats: • • • Read Message on page 8-19 Write-Data (Nontutorial) Message on page 8-19 Write-Tutorial-Mask Message on page 8-20 Read Message Data blocks read from a terminal that responds to polling have the following form: message = STX id aid seq {oc -data-}...
Write-Tutorial-Mask Message TINET Multipoint Supervisor Protocol wcc = write control %060 = all off character: %060 LOR %10 = REENTER light on %060 LOR %04 = ALARM on %060 LOR %02 = ENTER light on %060 LOR %01 = VALID light on oc = order code: %037 = SF = start field %021 = DC1 = device control - 1 (output to auxiliary device 1) %022 = DC2 = device control - 2 (output to auxiliary device 2) lc = light code: (used only if designated order code = SF) %060 or %077 = all FIELD ID lights off %060 + light
File-System Errors TINET Multipoint Supervisor Protocol fl = field length: %060 + length {0:15} (0 = unlimited) (message length = 6 + 2 * the number of light code entries/field length pairs) Note. Output to an auxiliary port can be included in this message format. The maximum number of recognized light code/field length pairs is ten; any light code/ field length pairs after the tenth pair are ignored.
Line Action by Procedure Call TINET Multipoint Supervisor Protocol Line Action by Procedure Call This subsection describes the TINET control sequences transmitted because of calls to file-system procedures. The actions of file-system procedures in response to line states and the reception of selected control sequences are also described.
WRITE Procedure TINET Multipoint Supervisor Protocol Table 8-7 lists the file-system errors that may occur on a READ. Table 8-7. READ File-System Errors Error Numbers Description Resultant Line State 0 No error. A station responded with a message. Message returned to the buffer of the application process. READ 160 Request is invalid for device state; protocol error. CONTROL 161 Impossible event occurred for line state CONTROL 171 No response received.
WRITE Procedure TINET Multipoint Supervisor Protocol Example 8-11. TINET Select Procedure Application Process TINET Terminal CALL WRITE(...) | | EOT --> | EOT ids NUL NUL STX-message-ETX LRC --> | | <-- EOT (WRITE completes) error = 0 Table 8-8 lists the file-system errors that may occur on a WRITE. Table 8-8. WRITE File-System Errors Error Number Description Resultant Line State 0 No error. A terminal was selected, and message in the buffer of the application process is written to it.
TINET Multipoint Supervisor Protocol CONTROL Procedure (Send EOT) CONTROL Procedure (Send EOT) The EOT sequence is used to reset the line following a READ error. You can send the EOT sequence by calling the CONTROL procedure and specifying operation 13 (Example 8-12). Example 8-12. CONTROL Procedure (Send EOT) CALL CONTROL (fnum,13) | EOT --> (CONTROL completes) error = 0 CONTROL Procedure (Send ENQ) An ENQ is sent to the transmitting terminal in response to an error 173 (transmission error) on a READ.
TINET Multipoint Supervisor Protocol Line-Error Handling Line-Error Handling The figures and error code descriptions in this subsection show Envoy line-error handling for READ and WRITE operations. This subsection includes: • • READ Operation on page 8-26 WRITE Operation on page 8-29 READ Operation Figure 8-6 shows the action of the supervisor station in response to line conditions on a READ.
READ Operation TINET Multipoint Supervisor Protocol Figure 8-6. TINET Multipoint Supervisor READ CALL READ... 1 Send Poll Address Wait for Response Timeout? Yes Error = 171 No Text with Error? Yes Retry Count = 0? Yes Error = 173 No No EOT Received? Send NAK Yes No List Done? Yes No Continuous Polling? Yes Delay for Polling No No Poll Done? Yes Error = 176 Text Overrun? Yes Retry Count = 0? No No Error = 177 Proper Protocol? No Error = 172 Yes Text Received? No Error = 0 CDT 051.
TINET Multipoint Supervisor Protocol Table 8-9 lists the error codes that can occur during a READ operation. Table 8-9.
WRITE Operation TINET Multipoint Supervisor Protocol WRITE Operation Figure 8-7 shows the action of the supervisor station in response to line conditions on a WRITE. Figure 8-7. TINET Multipoint Supervisor WRITE CALL WRITE...
Programming Example TINET Multipoint Supervisor Protocol Table 8-10 lists the error codes that can occur during a WRITE operation. Table 8-10.
OUTPUT TINET Multipoint Supervisor Protocol OUTPUT Table 8-12 lists the information displayed at a TINET terminal: Table 8-12. TINET Terminal Output ID Light Meaning Data Displayed 7 Credit is OK Authorization number (6 digits) 8 Credit is denied blank 9 Pick up card blank 10 Call center Center phone number (12 digits) Steps of Example Program The basic flow of the example program is: 1. The tutorial masks are written to all terminals in the network. 2. The network is polled. 3.
Steps of Example Program TINET Multipoint Supervisor Protocol Figure 8-8.
Steps of Example Program TINET Multipoint Supervisor Protocol The coding of the example program for a TINET multipoint supervisor is shown in Example 8-15: . Example 8-15. Program Code for TINET Multipoint Supervisor (Page 1 of 13) ! address list. LITERAL nul stx etx eot enq can sf addr^size num^entries = = = = = = = = = 0, 2, 3, 4, 5, %30, %37, 2, 8, poll^count = 4, poll^type = 0, no^poll = %200, line^readcount = 40; ! ! ! ! ! ! ! ! ! ! ! ! ! ! ASCII NULL character. ASCII STX character.
Steps of Example Program TINET Multipoint Supervisor Protocol Example 8-15. Program Code for TINET Multipoint Supervisor (Page 2 of 13) ! line errors. LITERAL no^response = 171, bad^reply = 172, max^naks = 173, overrun = 177, max^failures = 10; ! message formatting. LITERAL term^addr = 3, acct^field acctnum^fl banknum^fl expdate^fl refnum^fl trancode^fl amount^fl = = = = = = = 4, 15, 4, 4, 8, 2, 7; ! ! ! ! ! ! ! ! ! term address index from slinebuf[0]. account field index from msg[0].
TINET Multipoint Supervisor Protocol Steps of Example Program Example 8-15. Program Code for TINET Multipoint Supervisor (Page 3 of 13) ! write full tutorial mask wtm^full = [ STX, w^id, w^seq, wtm^cc, wtm^enter^wcc, wtm^acctnum^lcfl, wtm^banknum^lcfl, wtm^expdate^lcfl, wtm^refnum^lcfl, wtm^trancode^lcfl, wtm^amount^lcfl, ETX ]#, ! write data codes. wdata^cc = %060#, ! write data command code. wdata^valid^wcc = %061#, ! "validation". wdata^ok^lc = %067#, ! "credit okayed".
Steps of Example Program TINET Multipoint Supervisor Protocol Example 8-15. Program Code for TINET Multipoint Supervisor (Page 4 of 13) ! task definition. ! Each terminal is controlled by a separate "task." Control ! information for a task is kept in its "task control ! block." A task control block entry (and, therefore, a ! task is referenced by its "id"; a task’s id is the same as ! the corresponding terminal’s address-list entry number in ! the poll list.
TINET Multipoint Supervisor Protocol Steps of Example Program Example 8-15. Program Code for TINET Multipoint Supervisor (Page 5 of 13) ! ! ! ! ! ! ! ! ! ! ! ! This procedure performs the line polling function. It is initially (that is, during task startup) called by each task after the task writes its tutorial mask. At this time, the return address for each task is saved in the task’s task control block. However, polling is not initiated during startup.
TINET Multipoint Supervisor Protocol Steps of Example Program Example 8-15. Program Code for TINET Multipoint Supervisor (Page 6 of 13) line^cntread := 0; IF id <> -1 THEN ! save return to caller. BEGIN return^p := l[stack^p]; return^e := l[stack^e]; return^l := l[stack^l]; buf^addr := @buffer; cnt^addr := @count^read; END; IF start THEN CALL return^to^task (-1); ! return to ! start^up. ! set ’S’ above task’s data areas. STACK (system^call^base); CODE (SETS); ! poll the network.
TINET Multipoint Supervisor Protocol Steps of Example Program Example 8-15. Program Code for TINET Multipoint Supervisor (Page 7 of 13) ! This procedure is used to select and write to a terminal. PROC write^line (id, buffer, write^count); INT id, .buffer, write^count; BEGIN ! set system call stack base. STACK (system^call^base); CODE (SETS); ! set entry number into message control word. linebuf := id; ! move data into line buffer.
TINET Multipoint Supervisor Protocol Steps of Example Program Example 8-15. Program Code for TINET Multipoint Supervisor (Page 8 of 13) ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! This procedure controls each task. It is called during startup, once for each task, to establish each task’s data area. All control information pertaining to a given terminal is kept in this procedure’s local data area. Therefore, each terminal’s environment is maintained separately from the other’s.
TINET Multipoint Supervisor Protocol Steps of Example Program Example 8-15. Program Code for TINET Multipoint Supervisor (Page 9 of 13) INT .limit[0:0]; ! used to compute task stack size. IF start THEN BEGIN ! calculate task stack size. task^space := (@limit ’-’ @l) ’+’ call^space; ! calculate stack base for system calls.
TINET Multipoint Supervisor Protocol Steps of Example Program Example 8-15. Program Code for TINET Multipoint Supervisor (Page 10 of 13) IF invalid^expdate THEN BEGIN expdate := 0; sp ’:=’ [ wtm^expdate^lcfl END; IF invalid^refnum THEN BEGIN refnum := 0; sp ’:=’ [ wtm^refnum^lcfl END; ] -> @sp; ] -> @sp; IF invalid^trancode THEN BEGIN trancode := 0; sp ’:=’ [ wtm^trancode^lcfl ] -> @sp; END; IF invalid^amount THEN BEGIN amount := 0; sp ’:=’ [ wtm^amount^lcfl ] -> @sp; END; END ! partial write tutorial.
Steps of Example Program TINET Multipoint Supervisor Protocol Example 8-15. Program Code for TINET Multipoint Supervisor (Page 11 of 13) send^full^mask := 1; END; ! display credit check result. ! send partial tutorial mask or result of credit ! check. sp := ETX; @sp := @sp[1]; CALL write^line (id, out^buffer, @sp ’-’ @sout^buffer); END; ! while 1 loop. END; ! task. ! This procedure is called during task startup to save the ! return address to the start^up procedure.
Steps of Example Program TINET Multipoint Supervisor Protocol Example 8-15. Program Code for TINET Multipoint Supervisor (Page 12 of 13) ! ! ! ! ! ! ! ! ! ! ! ! This procedure performs the task-startup function. 1. The startup message is read from the $RECEIVE file. 2. The line is opened and defined. 3. Each task (that is, poll^count tasks) is started: -The stack base for task "i" is calculated. The ’S’ register is set to this value.
TINET Multipoint Supervisor Protocol Steps of Example Program Example 8-15. Program Code for TINET Multipoint Supervisor (Page 13 of 13) ! define the line. CALL DEFINELIST (linefnum,addr^list,addr^size, num^entries, poll^count,poll^type); IF < THEN CALL ABEND; ! start the line tasks. start := 1; base := @s; CALL save^return (@ret); i := -1; WHILE ( i := i + 1 ) < poll^count DO BEGIN ! set stack base for task "i". STACK (base + i * task^space); CODE (SETS); ! start a task.
TINET Multipoint Supervisor Protocol Envoy Application Programming Manual—427159-001 8- 46 Steps of Example Program
9 Burroughs Point-To-Point Protocol The Burroughs point-to-point protocol enables an application process to act as a station in a Burroughs dedicated point-to-point contention network.
Burroughs Point-To-Point Protocol Application Process Interface Application Process Interface An application process acting as a station in a Burroughs point-to-point network interacts with Envoy and the remote station by way of Guardian 90 file-system procedure calls.
Burroughs Point-To-Point Protocol Line Contention Line Contention With a point-to-point line, both stations can bid for the line simultaneously. Because of this, one station is designated the primary station and the other the secondary. If both stations bid at once, the primary has precedence. For Envoy, the primary and secondary designations are made when issuing the ADD DEVICE command and can be altered by a call to the SETMODE procedure.
Burroughs Point-To-Point Protocol File-System Procedures Table 9-2. CONTROL Operations for Burroughs Point-to-Point Operation Description 13 Sends EOT (end of transmission). Used to clear the network after an error occurs. 15 Enables RVI (reverse interrupt) 17 Enables connection by setting the data terminal ready (DTR) signal. 18 Disables connection by clearing DTR. CLOSE Terminates access to a data communications line.
Message Formats Burroughs Point-To-Point Protocol SETMODE Alters the line characteristics (Table 9-3). Table 9-3. SETMODE Operations for Burroughs Point-to-Point Operation Parameter Description 15 1 Sets timeout duration in 10-millisecond units. 2 Sets number of times to retry. 1 Sets line type. .<11> 0: Disables ID exchange. 16 1: Enables ID exchange. .<13> 0: Specifies secondary. 1: Specifies primary. .<14:15> 0: Specifies point-to-point, nonswitched.
Normal Text Burroughs Point-To-Point Protocol Messages must be formatted according to protocol rules. Prior to transmitting a message, the specific control characters for a particular message type (such as heading, text, or transparent text) must be placed in the message by the application process. When a message is received, the control characters are returned in the data to indicate the type of message received.
File-System Errors Burroughs Point-To-Point Protocol Table 9-5. Lowercase Letters for Block Number Block Number bl# 5 u 6 v 7 w Note. It is advisable to use message-block numbers as a standard practice; it is easier to write an application program if the current message is identified at all times. File-System Errors Upon completion of a file-system request, the Compaq application process should check for the Guardian 90 file-system error codes listed in Table 9-6. Table 9-6.
Errors 162 and 171 Burroughs Point-To-Point Protocol General file-system errors (Table 9-7) are also possible: Table 9-7. General File-System Errors Error Code Description 10-29 Coding or access problem 30-33 System configuration problem 120-199 Device hardware problem 200-255 Path error Errors 0, 163-168, and 171 are normal occurrences. Errors 163 and 167, for example, indicate that the remote station has reset the line to the CONTROL state.
Line Action by Procedure Call Burroughs Point-To-Point Protocol Line Action by Procedure Call This subsection describes the Burroughs point-to-point line-control sequences transmitted because of calls to file-system procedures. It also describes the actions of file-system procedures to line states and the reception of selected control sequences.
READ Procedure Burroughs Point-To-Point Protocol Table 9-9 shows the file-system errors that may occur on an initial READ. Table 9-9. Initial READ File-System Errors Error Numbers Description Resultant Line State 0 No error. A station responded with a message. Message is returned to the buffer of the application process. READ 160 Request is invalid for device state; protocol error. CONTROL 161 Impossible event occurred for line state. CONTROL 171 No bid received.
READ Procedure Burroughs Point-To-Point Protocol Note that the application process may acknowledge the previous message with an RVI interrupt sequence instead of the normal ACK by performing an enable RVI control operation (CONTROL 15) before calling READ. If the remote gives up its master status by sending an EOT instead of another message, the READ completes with error 163. Table 9-10 lists the file-system errors that may occur on a continuation READ. Table 9-10.
WRITE Procedure Burroughs Point-To-Point Protocol Example 9-3. Initial READ (Line in WRITE State) Local line state = WRITE CALL READ(...) | EOT --> | | ACK --> | (READ completes) error = 0 line state = READ Remote <-- ENQ (bid) <-- message The file-system errors that may occur on an initial READ in a WRITE state are the same as those for an initial READ in a CONTROL state. WRITE Procedure The WRITE procedure is used to select and transmit messages to a tributary station.
Burroughs Point-To-Point Protocol WRITE Procedure Table 9-11 lists the file-system errors that may occur on an initial WRITE. Table 9-11. Initial WRITE File-System Errors Error Number Description Resultant Line State 0 No error. Message was received and is in the buffer of the application process. WRITE 161 Impossible event occurred for line state. CONTROL 162 Operation timed out. No acknowledgment of the message was received within the timeout limit.
WRITE Procedure Burroughs Point-To-Point Protocol Continuation WRITE (Line in WRITE State) All WRITEs following the initial one are continuation WRITEs. A continuation WRITE (Example 9-5) causes Envoy, on behalf of the application process, to send the message in the buffer of the application process to the remote station. The call to the WRITE procedure completes when the remote station acknowledges the message.
Burroughs Point-To-Point Protocol CONTROL Procedure (Send EOT) Table 9-12. Continuation WRITE File-System Errors (page 2 of 2) Error Number Resultant Line State Description 173 Transmission error. Text was received with a character-parity error or a block check character error. A NAK was sent, and the message was retransmitted the number of times specified by the retry value. CONTROL 177 Text overrun.
CONTROL Procedure (Enable RVI) Burroughs Point-To-Point Protocol Example 9-7. CONTROL Procedure (Enable RVI) Local | (READ completes) line state = READ error = 0 Remote <-- message CALL CONTROL(fnum,15) | (CONTROL completes) error = 0 line state = READ CALL READ(...) | DLE ACK --> | (READ completes) error = 163 line state = CONTROL <-- EOT CALL WRITE(...
10 Asynchronous Line Supervisor Protocol The asynchronous line supervisor protocol is a general-purpose asynchronous linehandler. It provides a straight-through connection to the communications line, with the user application performing all line-control and protocol functions. You can use this protocol to connect devices that support non-standard asynchronous interfaces.
Protocol Capabilities Asynchronous Line Supervisor Protocol Protocol Capabilities This protocol offers the following features: • • • • • • • Data from the communications line is placed into memory one character (1 byte) at a time. The protocol then packs two characters in each word before passing text to the application process. Data in variable length blocks is returned by way of file-system procedures. The blocks may not exceed a quarter of the configured dedicated buffer.
Read-Only Mode Asynchronous Line Supervisor Protocol Note. Characters that are stripped are not included in the read count. Default values for the TCHAR modifier are provided in Table 10-1. Table 10-1. Default Values for Termination and Strip Characters TCHAR Octal Value Meaning TCHAR1 200 Strip zeroes. TCHAR2 377 Strip idles TCHAR3 4 Send interrupt on EOT TCHAR4 3 Send interrupt on ETX You cannot specify termination and strip characters in your application through a SETMODE command.
Asynchronous Line Supervisor Protocol Application Process Interface Envoy passes data to the application when a buffer fills or when a defined timeout interval occurs on the line. All remaining data in the buffer is passed when no input data is detected within a defined timeout interval. Buffers are always available on the line to prevent the loss of data from the line.
Polling by an Asynchronous Supervisor Asynchronous Line Supervisor Protocol Figure 10-1. Asynchronous Line Supervisor Polling CALL OPEN... nowait 2 CALL WRITEREAD (poll sequence) The Network is Polled Any Response? No Timeout Completes Error = 171 Yes READ Completes Application Checks Response Is Response Valid? No Invalid Response is Handled by the Application Yes CALL READ... READ Completes The Requested Text from the Terminal is Processed 1 Go to Select Sequence CDT 054.
Selecting by an Asynchronous Supervisor Asynchronous Line Supervisor Protocol Selecting by an Asynchronous Supervisor An application process acting as a supervisor station initiates selecting by using the WRITEREAD procedure to send a select sequence and to accept the response.of the addressed terminal (Figure 10-2). Note. Only an asynchronous supervisor can address specific terminals through the polling and selecting procedures. A read-only line cannot use these procedures. Figure 10-2.
Asynchronous Line Supervisor Protocol Retries Retries Line operations are subject to transmission errors such as of line errors, nonresponding terminals, and incorrect modem-line states. When these types of errors occur, Envoy passes an error indication to the application process. The application must then determine what action to take for recovery and retries. Note. Envoy does not retry operations for the asynchronous line supervisor protocol.
Asynchronous Line Supervisor Protocol File-System Procedures When a READ operation times out, it returns either of the following things to the application process: • • Whatever is left in the buffer A timeout indication For read-only lines, the application process must issue another READ through filesystem procedures after each block of text is returned. Failure to do so may result in a buffer overflow and in a loss of data from the read-only line. File-system timeouts are specified by an AWAITIO call.
File-System Procedures Asynchronous Line Supervisor Protocol FILEINFO Returns error information and characteristics about an open line. OPEN Establishes communications with a line. A line can be opened by only one process (and its backup) at a time. READ Solicits data from the line. When a terminal responds on the input line by sending a message, the terminal’s message is returned to the application process.
File-System Procedures Asynchronous Line Supervisor Protocol Table 10-5. SETMODE Operations for Asynchronous Line Supervisor (page 2 of 2) Operation Parameter Description 3 = 134.
Message Formats Asynchronous Line Supervisor Protocol WRITE Transmits data to a terminal. The call to WRITE causes Envoy to transmit a message on the line to the terminal. (This call cannot be used by read-only lines.) WRITEREAD Performs a WRITE sequence on the line followed by a READ sequence. (The READ accepts a response.) This procedure allows an application process to perform polls and selects to a terminal network. (This call cannot be used by read-only lines.
Asynchronous Line Supervisor Protocol File-System Errors File-System Errors Upon completion of a file-system request, the Compaq application process should check for the Guardian 90 file-system error codes listed in Table 10-6. Table 10-6. Asynchronous Line Supervisor File-System Errors Error Code Description 0 Operation successful 111 Operation aborted because of break 120 Data parity error.
Line Action by Procedure Call Asynchronous Line Supervisor Protocol Line Action by Procedure Call This subsection describes the asynchronous and simplex line-control sequences transmitted because of calls to file-system procedures.
Asynchronous Line Supervisor Protocol READ Procedure Table 10-10. CONTROL 18 and Switched Versus Nonswitched Lines Line Type Usage of CONTROL 18 Switched Can be used to turn off DTR (data terminal ready). Nonswitched Cannot be used. DTR cannot be turned off. When the line is opened, DSR (data set ready) is always enabled. If DSR drops during any I/O request, an error 140 (modem error) occurs, indicating the loss of the line.
READ Procedure Asynchronous Line Supervisor Protocol Example 10-1. MCW and the Message Block Number Application Process Asynchronous Terminal CALL READ (...) | Line is now set to receive | data if it was not set already | | <-- message | | | <-- message (READ completes) if buffer block filled or if termination character detected or if half-duplex and carrier drops or if timeout interval with no more data error = 0 MCW.
Asynchronous Line Supervisor Protocol READ Buffering Table 10-11. File-System Errors After a READ (page 2 of 2) Error Numbers Description 171 No response received. The line did not receive any message during defined timeout period. READ still active on line. Not returned by READ continuous lines. 173 Transmission error. The line detected a parity error and the read aborted. 177 Text overrun. Data overrun occurred in the line buffer and the READ aborted.
WRITE Procedure Asynchronous Line Supervisor Protocol WRITE Procedure The WRITE procedure is used to transmit a message to the line. A WRITE causes Envoy, on behalf of the application process, to initiate a transmission to a terminal on the line. The WRITE procedure completes when the entire message is sent. The successful transmission of the message is indicated by a condition code of CCE (Example 10-2). Example 10-2. WRITE Procedure Application Process Asynchronous Terminal CALL WRITE (...
CONTROL 11 and CONTROL 17 (Set DTR) Asynchronous Line Supervisor Protocol Example 10-3. WRITEREAD Procedure Application Process Asynchronous Terminal CALL WRITEREAD(message...) | | Transmit enabled and initiated | on line. | (message...) --> | (WRITE completes) | | Line now set to receive. | | <-- message (READ completes) error = 0 MCW.<8:15> contains message block number for this line The file-system errors for the WRITEREAD procedure are the same as the errors for the READ and WRITE procedures.
Asynchronous Line Supervisor Protocol CONTROL 15 and SETMODE 15 (Break) Table 10-14 shows the SETMODE procedures needed to define the different types of break characteristics. Table 10-14. Break Characteristics Defined by SETMODE 15 Break Type Required SETMODE Procedures Description Noncontinuous SETMODE 15, parm2 .<14> = 0 Specifies noncontinuous output break. SETMODE 15, parm1 = n Specifies the timeout interval in 10-millisecond units. The break signal lasts for the specified time interval.
Asynchronous Line Supervisor Protocol CONTROL 17 Procedure (Automatic Speed Detection) Example 10-5 shows how to define a continuous break: Example 10-5. Define a Noncontinuous Break CALL SETMODE (fnum,15,,,old^value);! Obtains current values CALL SETMODE (fnum,15,timeout,2); CALL CONTROL (fnum,15); ! line in "space" condition. ! CONTROL completes immediately. ! error = 0. CALL WRITE (fnum,....); ! output break disabled and WRITE ! active.
Line-Error Handling Asynchronous Line Supervisor Protocol Figure 10-3. Asynchronous Line Supervisor READ Operation CALL READ... Read count too large ? Yes Error = 21 No Receiver enabled Wait for response Yes Timeout? No Text received? Yes Error = 0 No Yes READ only? No Error = 171 Data parity error? Yes Error = 120 No Text with error? Yes Error = 173 No Text overrun? Yes Error = 177 No Text received ? Yes Error = 0 CDT 056.
Line-Error Handling Asynchronous Line Supervisor Protocol Figure 10-4 shows the action of the supervisor station in response to line conditions on a WRITE operation. Figure 10-4. Asynchronous Line Supervisor WRITE Operation CALL WRITE... Enable transmit line and send message Wait for complete Yes Timeout? Error = 171 No Error = 0 CDT 057.
Read-Only Programming Examples Asynchronous Line Supervisor Protocol Read-Only Programming Examples Example 10-6 shows the use of read-only mode with a simplex line. The application program reads from a simplex line and writes to a line printer. Example 10-6. Read-Only Programming Example (Page 1 of 2) ! Simplex programming example: ! Read-only line to a RS-232C printer. INT t^count, rlineno rlinedef[0:12], plineno, plinedef[0:12], buffer[0:81]; STRING .rline := @rlinedef ’<<’ 1, .
Asynchronous Line Supervisor Protocol Read-Only Programming Examples Example 10-6. Read-Only Programming Example (Page 2 of 2) t^count := 75; ! set timeout value 750 ms. CALL SETMODE (rlineno,set^tmout,t^count); t^count := full^plex + r^continuous; ! set line type read ! only. CALL SETMODE(RLINENO,SET^LTYPE,T^COUNT); next^rec: CALL READ (rlineno,buffer,80,t^count); ! read from line. IF < THEN GOTO next^rec; rpbuff[t^count + 1] := CR; ! set printer CR/LF.
Asynchronous Supervisor Programming Example Asynchronous Line Supervisor Protocol Asynchronous Supervisor Programming Example The programming examples in Example 10-8 through Example 10-11 show the following operations for an asynchronous supervisor: • • • • Poll a Terminal and Read a Message on page 10-26 Select a Terminal and Send a Message on page 10-26 Send a Break Signal on page 10-27 Enable and Disable a Switched Line on page 10-27 The declarations shown in Example 10-7 are used in the programmin
Asynchronous Line Supervisor Protocol Asynchronous Supervisor Programming Example The example in Example 10-8 demonstrates the sequence involved in polling a terminal network and reading a message. Example 10-8. Poll a Terminal and Read a Message INT PROC poll^term; BEGIN INT index := 0; FOR index := 0 TO num^entries DO BEGIN sbuff ’:=’ addr^list[index * addr^size] FOR addr^size; CALL WRITEREAD (lineno,buffer,addr^size,80,r^count); IF < THEN BEGIN ! handle the error.
Asynchronous Line Supervisor Protocol Asynchronous Supervisor Programming Example The example in Example 10-10 demonstrates the sequence involved in sending a break signal on the line. Example 10-10. Send a Break Signal SUBPROC break (duration); INT duration; BEGIN INT old^parm[0:1]; CALL SETMODE (lineno,set^tmout,,,old^parm); CALL SETMODE (lineno,set^tmout,duration,0); CALL CONTROL (lineno,snd^brk); IF < THEN BEGIN ! handle the error.
Asynchronous Line Supervisor Protocol Asynchronous Supervisor Programming Example Envoy Application Programming Manual—427159-001 10 -28
A ASCII Character Set Table A-1 lists the octal values of the ASCII character set. It also provides the meanings of the control characters used by the various Envoy protocols. Table A-1.
ASCII Character Set Table A-1.
ASCII Character Set Table A-1.
ASCII Character Set Table A-1.
ASCII Character Set Table A-1.
ASCII Character Set Envoy Application Programming Manual—427159-001 A- 6
B ASCII to EBCDIC Code Conversion Compaq systems translate ASCII code to EBCDIC code, and EBCDIC code to ASCII code as shown in Table B-1. Under each column heading you will find the octal number followed by the hexadecimal number for each character or mnemonic. Table B-1.
ASCII to EBCDIC Code Conversion Table B-1.
ASCII to EBCDIC Code Conversion Table B-1.
ASCII to EBCDIC Code Conversion Table B-1.
ASCII to EBCDIC Code Conversion Table B-1.
ASCII to EBCDIC Code Conversion Table B-1.
ASCII to EBCDIC Code Conversion Table B-1.
ASCII to EBCDIC Code Conversion Table B-1.
C File-System Procedures Appendix C summarizes the various Guardian 90 file-system procedures that an application program uses to interact with asynchronous and byte synchronous data communications lines. The procedures are described fully in the Guardian Procedure Calls Reference Manual. The Guardian Procedure Calls Reference Manual provides an overview of the use of the file-system procedures.
File Number Parameters File-System Procedures WRITE[X] WRITEREAD[X] Regardless of whether you are using wait or nowait I/O, the following procedure calls must complete processing before control passes to the next instruction or statement: CANCEL CHANGELIST CLOSE DEFINELIST DEVICEINFO FILEINFO HALTPOLL OPEN SETMODE An Envoy I/O process is characterized by direct control. Only one I/O request per line may be pending at any time and that request must be completed before another is accepted for the same line.
Buffer Parameter File-System Procedures the tag value associated with the I/O call being completed. For example, the following sequence in Example C-2 shows the use of a tag: Example C-2.
Errors File-System Procedures Errors An error number is associated with each file-system procedure call. The number can be obtained by calling the FILEINFO procedure. External Declarations for File-System Procedures Like all other procedures in an application program, the file-system procedures must be declared before being called. These procedures are declared as residing outside the application program. The external declarations for these procedures are provided in a system file named $SYSTEM.SYSTEM.
AWAITIO[X] File-System Procedures currently has opened, filenum is -1. When the AWAITIO[X] call completes processing, Envoy sets filenum to reflect the file number of the particular line on which the I/O completion occurred. For example, if you use SETMODE 30 to allow nowait I/O operations to complete in any order, you should use AWAITIO[X] with filenum -1 to find out which operation has completed.
AWAITIO[X] File-System Procedures >0D = Wait the specified amount of time for a completion. In this case, timelimit specifies the desired time interval in .01-second units. If the AWAITIO[X] call can logically complete an incomplete I/O operation within the specified time period, it does so, and control passes to the next sequential statement or instruction in the calling process.
CANCEL File-System Procedures CANCEL The CANCEL procedure is used to cancel the oldest incomplete operation on a nowait file. This procedure can only be used on a full-duplex line. The form of the CANCEL procedure is: CALL CANCEL ( filenum); filenum !i input INT:value is the number of an open file whose oldest incomplete operation you want to cancel. Condition Codes < (CCL) Indicates that an error occurred (call FILEINFO). = (CCE) Indicates that the CANCEL procedure completed successfully.
CHANGELIST File-System Procedures For a tributary station, a call to the CHANGELIST procedure activates or deactivates the station (with regard to either polling or selecting) by altering the setting of the poll bit or select-state bit for a particular entry in the tributary’s address list. The form of the CHANGELIST procedure is: CALL CHANGELIST ( filenum , function , parameter ); filenum !i !i !i input INT:value is the number returned by the OPEN call that opened the line.
CHANGELIST File-System Procedures If the function value is -1, then the parameter value specifies the desired type of polling, as follows: 0 = Continuous polling. c>0 = Noncontinuous polling (traverse the poll list the specified number of times and then cease polling). If the function value is -2, then the parameter value has no meaning. The CHANGELIST procedure, however, expects to be passed three values and you must therefore supply a dummy parameter value.
CLOSE File-System Procedures CLOSE A call to the CLOSE procedure terminates access to the specified communications line. The call must be issued by the same process that opened the line. The form of the CLOSE procedure is: CALL CLOSE ( filenum ); filenum !i input INT:value is the number returned by the OPEN call that opened the line. In a CLOSE call, you supply this variable to Envoy.
CONTROL File-System Procedures operation input INT:value is an integer value you use to specify the desired control operation. Table C-1 summarizes the CONTROL codes and operations. Refer to the protocol sections 4 through 11 for additional information on CONTROL operations. parameter input INT:value is a subcode you use to further define the desired operation. tag input INT(32):value applies to nowait I/O only.
CONTROL File-System Procedures Table C-1. CONTROL Operation Codes (page 2 of 3) Operation Protocol Parameter Description .<0> 1:Performs specific poll on device indicated by station index value .
DEFINELIST File-System Procedures Table C-1. CONTROL Operation Codes (page 3 of 3) Operation Protocol Parameter Description 1 0: Sets DTR true 1: Sets DTR true and waits for DSR to become true.
DEFINELIST File-System Procedures CALL DEFINELIST ( , , , , , filenum filenum address-list address-size num-entries polling-count polling-type ); !i !i !i !i !i !i input INT:value is the number returned by the OPEN call that opened the line. In a DEFINELIST call, you supply this variable to Envoy. address-list input INT:ref is the name of an integer array you supply; it contains one or more poll addresses and select addresses.
DEFINELIST File-System Procedures Table C-2. Polling Type for Supervisor Stations Polling Type Parameter Description 0 Envoy should perform continuous poll 1-127 Envoy should poll the specified number of polling cycles For a tributary station, the polling type parameter (Table C-3) specifies how Envoy should respond when a non-active defined address is selected. Table C-3.
DEFINELIST File-System Procedures Example C-3. Address List LITERAL addr^size = 3, num^entries = 6, polling^count = 3, SYN = %26, ENQ = 5; STRING .saddr^list [ SYN, SYN, SYN, SYN, SYN, SYN, [0:addr^size * “AA01”, ENQ, “BB01”, ENQ, “CC01”, ENQ, “aa01”, ENQ, “bb01”, ENQ, “cc01”, ENQ ]; num^entries * 2 ! entry 0, trib ! entry 1, trib ! entry 2, trib ! entry 3, trib ! entry 4, trib ! entry 7, trib 1 2 3 1 2 3 1] := poll. poll. poll. select. select. select.
DEVICEINFO File-System Procedures Example The following code in Example C-4 shows how to define an address list array and pass it to the DEFINELIST procedure for continuous polling: Example C-4. Code to Define an Address List Array LITERAL addr^size num^entries polling^count polling^type SYN ENQ no^poll STRING .
DEVICEINFO File-System Procedures device-type output INT:ref:1 is the name of a one-word integer variable into which Envoy places the configured device type and subtype for the specified communications line. The format of this parameter is listed in Table C-4. physical record length output INT:ref:1 is the name of a one-word integer variable into which Envoy places the configured intermediate block size. The block size is originally set through the SYSGEN modifier ITBSIZE.
FILEINFO File-System Procedures $LINE3 is configured as a TINET multipoint supervisor, then dev^type contains the following value of %711: MSB LSB 0 . 0 1 . 0 2 . 0 3 . 0 4 . 0 \ 5 . 0 _ 6 . 0 _ 7 7 . 1 _ 8 . 1 _ 9 . 1 / 10 . 0 \ 11 . 0 _ 12 . 1 _ 9 13 . 0 _ 14 . 0 _ 15 . 1 / If $LINE3 is configured with an intermediate block size of 100, then phys^rec^length contains the decimal value “100.
FILEINFO File-System Procedures file-name input,output INT:ref:12 is the name of a 12-word integer variable into which Envoy places the configured device name of the specified line. logical-device-number output INT:ref:1 is the name of a one-word integer variable into which Envoy places the configured logical device number of the specified line. This parameter is invalid with filename; use filenum.
HALTPOLL File-System Procedures zzzz (bits 12 to 15) specify whether the line is configured for wait or nowait I/O: 0000 = wait I/O 0001 = nowait I/O Condition Codes < (CCL) = (CCE) Indicates that an error occurred (call FILEINFO). Indicates that the FILEINFO procedure was executed successfully. Examples CALL FILEINFO (fnum,error); where fnum is the name of the one-word integer variable specified in the OPEN call that opened the particular communications line.
OPEN File-System Procedures filenum input INT:value is the number returned by the OPEN call that opened the line. In a HALTPOLL call, you supply this variable to Envoy. Condition Codes < (CCL) = (CCE) Indicates that an error occurred (call FILEINFO). Indicates that the HALTPOLL procedure was executed successfully. Example CALL HALTPOLL (fnum); where fnum is the one-word integer variable specified in the OPEN call that opened the particular communications line.
OPEN File-System Procedures flags input INT:value is an integer value that you supply; its individual bits specify certain characteristics about the line.
READ[X] File-System Procedures If the OPEN call is issued by a backup process and any of the following is true, the OPEN call is rejected with a condition code of CCL (file-system error 12): • • • The specified file is not currently open by the primary process. The parameters specified do not match those supplied when the file was opened by the primary process. The primary process is not running.
READ[X] File-System Procedures The form of the READ[X] procedure is: CALL READ[X] ( filenum , buffer , read-count ,[ count-read] ,[ tag] ); filenum !i !o !i !o !i input (Use with both READ and READX) INT:value is the number returned by the OPEN call that opened the line. In a READ[X] call, you supply this variable to Envoy. buffer output INT:ref:* (Use with READ) STRING .EXT:ref:* (Use with READX) is the name of the integer array in the application program where the incoming data is to be placed.
SETMODE File-System Procedures Examples CALL READ (fnum,in^buffer,102); fnum is the name of the one-word integer variable specified in the OPEN call that opened the particular communications line. in^buffer is the name of the integer array in the application program where the received data is placed. The read count of 102 specifies an incoming message containing up to 100 bytes of data (this count also includes the two-byte MCW is expected to be received).
SETMODE File-System Procedures parameter-1 input INT:value is a subcode you use, in conjunction with the function value, to further define the desired mode setting operation. The SETMODE codes are shown in Table C-5 on page C-27. parameter-2 input INT:value is a subcode you use, in conjunction with the function value, to further define the desired mode setting operation. The SETMODE codes are shown in Table C-5 on page C-27.
SETMODE File-System Procedures Table C-5. SETMODE Operation Codes (page 2 of 4) Operation Parameter .<3> .<3> Description Analogous Modifier 1: Poll next station after EOT is received (BISYNC multipoint only) POLLONEOT 0: Enables incoming parity checking for ASYNC or SIMPLEX CHECK 1: Disables incoming parity checking for ASYNC or SIMPLEX NOCHECK 0: Normal BISYNC CRC calculation 1: SWIFT BISYNC CRC calculation .
SETMODE File-System Procedures Table C-5. SETMODE Operation Codes (page 3 of 4) Operation Parameter Description Analogous Modifier The threshold value. If the sum of NAKs received, BCC errors, format errors, and retries exceeds the threshold, these statistics are reported on the operator console. Refer to Appendix D, Statistics Messages for more detailed information on operator console messages 22 1 Modifies baud rate (bits per second) for asynchronous lines 0= 50 1= 75 2= 110 3= 134.
SETMODE File-System Procedures Table C-5. SETMODE Operation Codes (page 4 of 4) Operation 135 137 Parameter Description Analogous Modifier 2 = no parity NONE 1 Enable/disable parity checking for asynchronous lines .
SETMODENOWAIT File-System Procedures SETMODENOWAIT The SETMODENOWAIT procedure is identical to the SETMODE procedure, except that it is performed as a nowait operation and therefore includes the optional tag parameter. If you wish to use SETMODENOWAIT, the line must be opened for nowait I/O and you must logically complete the SETMODENOWAIT operation with a subsequent AWAITIO call. Note that if the line is opened for nowait I/O, you may use either SETMODE or SETMODENOWAIT.
WRITE[X] File-System Procedures last-params output INT:ref:2 is the name of a two-word integer array into which Envoy places the previous values of parameter-1 and parameter-2 for the specified SETMODENOWAIT function. The format of the array is: last-params[0] = parameter 1 value last-params[1] = parameter 2 value, if applicable If the SETMODENOWAIT call includes only function and last-params, the specified function is not performed.
WRITE[X] File-System Procedures The form of the WRITE[X] procedure is: CALL WRITE[X]( filenum , buffer , write-count ,[count-written] ,[tag]); filenum !i !i !i !o !i input (Use with WRITE and WRITEX) INT:value is the number returned by the OPEN call that opened the line. In a WRITE[X] call, you supply this variable to Envoy. buffer input INT:ref:* (Use with WRITE) STRING .
WRITEREAD[X] File-System Procedures Examples CALL WRITE (fnum,out^buffer,102); where fnum is the one-word integer variable specified in the OPEN call that opened the particular a communications line and out^buffer is the name of the integer array within the application program from which the outgoing data is to be received. The write count of 102 specifies that a message containing 100 bytes of data (this count also includes the two-byte MCW that is going to be transmitted).
WRITEREAD[X] File-System Procedures buffer input, output INT:ref:* (Use with WRITEREAD) STRING .EXT:ref:* (Use with WRITEREADX) is the name of the integer array in the application program from which the outgoing data is to be retrieved. The incoming data is subsequently placed there as well. The buffer’s first two bytes contain the MCW. write-count input (Use with WRITEREAD and WRITEREADX) INT:value specifies how many bytes are to be retrieved from the application buffer.
WRITEREAD[X] File-System Procedures Examples CALL WRITEREAD (fnum,buffer,52,102); where fnum is the name of the one-word integer variable specified in the OPEN call that opened the particular communications line. buffer is the name of the integer array in the application program to be used first for a WRITE operation and then for a READ operation. The write count of 52 specifies that we want to transmit a message containing 50 bytes of data (this count also includes the two-byte MCW).
D Statistics Messages Envoy prints statistics messages on the operator console • • • When a line's error threshold is exceeded When a path switch occurs When a line is closed. In the first two instances, the statistics counts are reset to zero. The error threshold is specified at system generation and can be respecified with a call to the SETMODE 18 procedure. Console messages have the following form: [msg no.] {time stamp FROM sender cpu, pin} message msg no.
Statistics Messages Envoy Application Programming Manual—427159-001 D- 2
E S-Series Changes to Envoy The NonStop™ Himalaya S-series server architecture affects I/O processes such as Envoy because a single data-communications concentrator replaces all former communications controllers. In addition, the management subsystem that controls the concentrator required changes to configuration operations. These basic changes mostly affect SYSGEN configuration and SCF.
LEOTRESYN and NOLEOTRESYN Modifiers S-Series Changes to Envoy Set CBSENSEOFF and CFSENSEOFF if monitoring of MODEM signals is not needed while a READ is in progress. LEOTRESYN and NOLEOTRESYN Modifiers D-series versions of Envoy Supports both LEOTRESYN and NOLEOTRESYN. G-series versions of Envoy Supports only LEOTRESYN. It does not support NOLEOTRESYN.
Reporting of Parity Error S-Series Changes to Envoy Reporting of Parity Error D-series versions of Envoy The 3603 controller does not return parity error. G-series versions of Envoy When data is received with parity error, error 120 is reported to the application. Half-Duplex Support for Asynchronous Lines D-series versions of Envoy Asynchronous lines can be either FULL or HALF duplex. G-series versions of Envoy HALF duplex is not supported for asynchronous lines.
Unit Numbers S-Series Changes to Envoy Unit Numbers While adding the device, unit number is not required, except for lines of subtype 30, 31, 32 and 33. FDX Line Changes Starting from this release, FDX lines (Write and Read) need to be MULTIed on a single line of any CLIP so as to get the same effect as that of COUPing these lines on units n and n+1 of a 3602 controller (where n = 0, 2, 4, 6) No Support for Auto-Call Unit ACU is not supported in G-series releases.
Glossary $ZZLAN. The process name of the ServerNet LAN systems access (SLSA) subsystem manager process that is started by the $ZZKRN Kernel subsystem manager process and maintained by the $ZPM persistence manager process. See also LAN manager (LANMAN) process. $ZZWAN. The process name of the wide area network (WAN) subsystem manager process. 3602. A communications controller supporting Envoy byte-synchronous protocols in CLX and Cyclone systems. This controller works only with Envoy. 3603.
Burroughs Point-to-Point Protocol. Glossary Burroughs Point-to-Point Protocol. A protocol that enables an application process to act as a station in a Burroughs dedicated point-to-point contention network. byte-synchronous data transmission (BISYNC). A data communications environment in which stations synchronize with each other by means of synchronous idle (SYN) characters. The stations communicate by using a standard set of control characters and control character sequences.
data link control (DLC). Glossary data link control (DLC). A set of functions associated with Layer 2 of the Open Systems Interconnection (OSI) reference model. These functions are responsible for reliable communication between two physically connected nodes. data link control (DLC) task. WAN DLC tasks support the equivalent to level 2 of the ISO/OSI Seven-Layer Model. The WAN DLC tasks execute in the SWAN concentrator communications line interface processor (CLIP).
EMS. Glossary terminal equipment. This standard has been generally accepted in business equipment. See also RS-232. EMS. See Event Management Service (EMS). end of text (EOT; ETX). Indicates the end of a message. If a message contains multiple transmission blocks, ETX terminates the last block of the message. End-of-text block (ETB) is used to terminate preceding blocks. The block check character (BCC) is sent immediately following an ETX. ETX requires a reply indicating the receiving station’s status.
Guardian Glossary Guardian. An environment available for interactive or programmatic use with the NonStop™ Kernel. Processes that run in the Guardian environment use the Guardian system procedure calls as their application program interface. half-duplex. A method of serial communications in which the data flow between two points can occur in only one direction at a time. This concept refers to the physical capability of the line. high PIN. A PIN that is greater than 255. See also low PIN.
logical device number Glossary low-cost nodes can be connected. One or more LANs can be connected to the system such that the LAN users can access the system as if their workstations were connected directly to it. logical device number. A number that identifies a particular I/O device in the system. Logical device numbers are assigned to physical I/O devices. low PIN. A PIN that ranges from 0 through 254. See also high PIN. MCW. Message control word.
persistence. Glossary PROCESS, and so forth. The object name uniquely identifies an object within the system. persistence. For the Subsystem Control Facility (SCF), the capability of a generic process to restart automatically if it was stopped abnormally. You configure this capability by specifying a nonzero AUTORESTART value in an ADD command. point-to-point. A data-link configuration between two stations.
sensitive command. Glossary sensitive command. One that can be issued only by a user with super-group access, by the owner of the subsystem, or by a member of the group of the owner of the subsystem. For Compaq communications subsystems, the sensitive commands can change the state or configuration of objects, start or stop tracing, or change the values of statistics counters. See also nonsensitive command. server.
Glossary Subsystem Programmatic Interface (SPI). Subsystem Programmatic Interface (SPI). A common, message-based interface that can build and decode messages used for communication between requesters (for example, a management application) and servers (Compaq subsystems). supervisor. The controlling station in a centralized, multipoint, data link. SWAN concentrator. See ServerNet WAN (SWAN) concentrator. switched line. A line configuration for circuit-switched networks such as a public telephone network.
wide area network (WAN) Glossary components including the WAN manager process, the ConMgr and WANBoot processes, and the WAN subsystem SCF interface. wide area network (WAN). A communication system that connects geographically dispersed sites or local area networks (LANs). WANs are primarily used to interconnect an organization’s voice, video, data, and computer business systems including LANs.
Index Numbers 10Base-T Ethernet connections 2-2 3602 byte-synchronous controller 2-2, E-1 3602 controller emulator 2-2 3603 asynchronous controller 2-2, E-1 3603 controller emulator 2-2 A ACK 3-1 Address list 2-16/2-18 ADM-2 multipoint supervisor protocol 7-1/7-46 protocol 1-8, 2-3 Architecture, Envoy subsystem 1-3 ASCII character set 2-1, 3-2, 3-5, 4-1, 4-5, A-1 ASCII-to-EBCDIC translation 3-5, 4-5, B-1 Asynchronous concentrator type 1-8 devices 2-1 environment 2-1 line supervisor protocol 10-1/10-27 prot
D Index CLIP 2-2, E-1 CLOSE procedure 1-11, 2-4, C-2, C-10 Command (OBEY) file 1-5, 1-11 Commands, interface 1-4 Communications line interface processor (CLIP) See CLIP Compaq NonStop™ TCP/IP 2-2, E-1 Concentrator type asynchronous 1-8 byte-synchronous 1-8 summary of 1-7 Condition code CCE 2-6 CCG 2-6 CCL 2-6 definition C-3 Configuration tools 1-10 Consultative Committee International Telephone and Telegraph (CCITT) polynomial 3-15 Contention line-bid situations 2-8 mode 3-1 resolving 3-6 Continuous break
F Index Envoy-SWIFT point-to-point protocol See SWIFT EOT control character 2-6 control sequence 2-23 error 2-7 received 3-5 sequence 3-5 Error conditions 2-22 messages logging 1-5 obtaining error number C-4 Ethernet 2-2 Event Management Service (EMS) See EMS Event messages display 1-4 interface 1-4 log 1-6 F Fast select 7-21 FILEINFO procedure 2-5/2-6, C-2, C-4, C-19 Full-duplex protocol 1-8, 2-3, 6-1/6-8 G Guardian 90 file-system error codes 3-16, 4-25, 5-19, 6-8, 7-24, 8-21, 9-7, 10-12 procedures 1-1
N Index Motorola MC68EN360 quad integrated communications controller (QUICC) chip 2-2, E-1 Multileaving option 3-1, 3-7 Multipoint configuration 2-15 station 2-16 supervisor 1-8 tributary 1-8 N NAK control sequence 2-22 NASDAQ lines 6-3 Negative acknowledgment (NAK) 2-20 Noncontinuous polling 2-18 Nonresponding station list 4-21 NonStop™ Kernel 2-1 Normal text 3-12, 4-23, 5-17, 6-7, 7-20, 9-6 O OPEN procedure 1-11, 2-5, 2-12, C-2, C-22 Operations environment, DSM 1-11 P Parameter buffer C-3 file number
T Index SCF (continued) configuration tool 1-10 definition 1-11 interactive interface 1-4 objects 1-9 role within DSM 1-5 SCP 1-5, 1-6 Secondary contention resolution 3-2 station 1-7 Select address 2-16/2-17, 4-2 Selection inactive bit 2-20 operation 2-20 Send function 7-23 timeout 2-8 Sequential select 7-20 ServerNet LAN Systems Access (SLSA) subsystem 2-2, E-1 ServerNet wide area network (SWAN) concentrator See SWAN SETMODE operation codes C-27 procedure 2-5, 2-12, 2-22, C-2, C-26 SETMODENOWAIT procedur
V Index Timeout (continued) value 3-6 when specified 2-12, 2-22 TIMEOUT modifier 3-6, 4-6 TINET multipoint supervisor protocol 8-1/8-45 protocol 1-8, 2-3 Tokens 1-5 Transaction-oriented applications 1-1 Transparent text 3-5, 3-12, 3-14, 4-5, 4-23, 5-17, 6-7 Tributary station 1-7, 2-16/2-18 TSM client application 1-11 components of 1-11 configuration tool 1-10 definition 1-6 TTD NAK protocol sequence 3-6 WRITE (continued) state 2-10 WRITEREAD procedure 2-5/2-6, 2-11, 3-25, 4-33, 5-27, 7-31, 10-17, C-2, C-
