Data Communications Library 6100 BSC Programming Manual Abstract Part Number This manual describes the 6100 BSC protocol module. It provides information for application programmers and system managers.
Document History Edition Part Number Product Version Operating System Version Date First Edition 82412 CP6100 B00 GUARDIAN B00 March 1985 New editions incorporate any updates issued since the previous edition. Copyright All rights reserved. No part of this document may be reproduced in any form, including photocopying or translation to another language, without the prior written consent of Tandem Computers Incorporated. Copyright 1985 Tandem Computers Incorporated.
CONTENTS PREFACE.................................................. vii SECTION 1: INTRODUCTION TO 6100 BSC..................... Features of the 6100 BSC Product....................... 6100 BSC Concepts and Context.......................... Station Types........................................ Message Formats...................................... Data Link Control Procedures......................... Line Configuration Options...........................
Contents START/STOP OPERATION Request......................... START/STOP TRACE Request and Response................ WRITE Request and Response........................... WRITEREAD Request and Response....................... Status Codes and Details............................... 3-51 3-53 3-54 3-56 3-59 APPENDIX A: FILE SYSTEM ERROR CODES..................... A-1 APPENDIX B: BSC PROGRAMMING EXAMPLE..................... B-1 APPENDIX C: ASCII/EBCDIC CODE TRANSLATION TABLE......... C-1 INDEX..........
Contents 3-4 3-5 3-6 3-7 3-8 3-9 3-10 Line Bid, Contention and Resolution.................. Data Transfer........................................ Reverse Interrupt and Line Turnaround................ Conversational Reply................................. Relinquishing the Line (Options)..................... WRITEREAD Buffer..................................... Requests and Responses in Order by Function Code.....
PREFACE This book describes the BSC protocol available for use with the CP6100 I/O process. The organization and content of the book are as follows: • Section 1 introduces the 6100 BSC protocol module. It briefly reviews the characteristics of BSC protocol and discusses configuration options that affect the protocol. • Section 2 is a detailed discussion of the BSC protocol module, its architecture and some important aspects of its internal operation.
SECTION 1 INTRODUCTION TO 6100 BSC Binary Synchronous Communications (BSC) is a line protocol developed by the International Business Machines Corporation. It is defined in the document: General Information--Binary Synchronous Communications (IBM Order No. GA27-3004-2) The definition of BSC includes rules for point-to-point and multipoint operation. It provides for two-way alternate transmission over half or full duplex lines, and the use of leased or switched (dialup) facilities.
Features of the 6100 BSC Product FEATURES OF THE 6100 BSC PRODUCT The BSC protocol module runs in a Line Interface Unit (LIU) on a 6100 communication subsystem. It is downloaded from a disk file to the LIU, either when the system is cold-loaded or by operator request. A single copy of BSC controls one data communication line. (If you use the MULTI option in SYSGEN, one copy of CP6100 can control multiple lines, but each line has its own Line Interface Unit and copy of BSC.
Features of the 6100 BSC Product ----------------------------------------------------------------| | | SET CONFIGURATION - Supplies values for BSC line parameters,| | or replaces default ASCII <--> EBCDIC | | translation tables. | | | | FETCH CONFIGURATION - Retrieves current BSC line parameters | | or translation tables. | | | | FETCH STATISTICS - Retrieves line quality information, | | counts of different kinds of frames, | | and other statistics maintained by BSC.
Features of the 6100 BSC Product Other important features of the BSC module are: • BSC supports a single point-to-to-point link. • The maximum data rate on a link is 19200 bits per second. Either the modem or the LIU can supply the transmit clock. • The message formats are those specified in the IBM manual defining the protocol, with the following exceptions: BSC doesn't check for pad characters after an EOT or NAK sequence, nor does the receiver look for a SYN to occur at three-second intervals.
6100 BSC Concepts and Context 6100 BSC CONCEPTS AND CONTEXT Using 6100 BSC, a Tandem system communicates reliably with any of a large number of devices. Although higher-throughput protocols have been developed since BSC, there is probably none supported by as many computers, terminals, and other data communication devices. As we've already said, 6100 BSC is a point-to-point protocol: that is, it allows exactly two entities to communicate. Each communicating entity is called a station.
6100 BSC Concepts and Context • After sending a message or block to which an acknowledgement is expected, a station waits for a prescribed interval before retrying the transmission. The interval is 2.7 seconds for a primary station, 3 seconds for a secondary station. This difference ensures that if transmissions collide, the retry by the primary occurs before the retry by the secondary. NOTE 6100 BSC lets you set up a link in which both stations are primary, or both are secondary.
6100 BSC Concepts and Context Message Formats The most common reason for a point-to-point link is to let the two stations exchange application data. For example, a mainframe sends text to a terminal for presentation on its screen, and receives from the terminal the data it needs to accomplish a transaction. Alternatively, one station might act as a message switch, accepting data and routing it to one or more other stations.
6100 BSC Concepts and Context The exchange of data in 6100 BSC is half-duplex. At a given time, one station can transmit; the other responds to each transmission with an acknowledgement or reply. Thus a sending station finds out right away whether a transmission was received correctly, and whether the other station is still ready to accept data. These factors are important when you plan the messages for an application. You can build messages to suit the routing and transparency requirements of a link.
6100 BSC Concepts and Context Application-Supplied BSC-Supplied PAD SYN...SYN STX At Least 2 SYN Characters TEXT ETX BCC Accumulation Includes These Characters BCC PAD 1 or 2 Characters S5066-003 Figure 1-4. Basic Message Format If you were using a line monitor to observe the activity on the line, you would also see these other parts of the message, invisible to the application: • The leading pad.
6100 BSC Concepts and Context NOTE A programmer doesn't have to know the details of BCC computation. There are two basic kinds of block checking; you define in SYSGEN the one you want to use. The part of this section that describes line parameters tells you how to make the right choice. • The trailing pad. This character is present at the end of each transmission. It ensures that the modem transmits the last character--in this instance, the block check sequence--before it turns the transmitter off.
6100 BSC Concepts and Context Application-Supplied BSC-Supplied PAD SYN...SYN SOH HEADING DATA At Least 2 SYN Characters STX TEXT BCC Accumulation Includes These Characters ETX BCC PAD 1 or 2 Characters S5066-004 Figure 1-5. Message with Heading As the figure shows, the heading begins with the character SOH, which has a value of 01 hexadecimal in ASCII or EBCDIC.
6100 BSC Concepts and Context MESSAGE BLOCKING. In the two formats shown so far, the whole message was packaged in one unit, with one block check sequence and one occasion for acknowledgement by the remote station. BSC also lets you divide a message into blocks. There are several reasons you might choose to divide (or "block") a message: • The remote device might have a buffer size less than that of the complete message.
DATA Figure 1-6. DATA Application-Supplied BSC-Supplied Receiving Station: ETB BCC PAD ITB BCC BCC Accumulation DATA TEXT TEXT ETX BCC PAD SYN...SYN ACK0 PAD Acknowledges Whole Message ETX BCC PAD BCC Accumulation ITB BCC SYN SYN BCC Accumulation SYN SYN STX Acknowledges Block #2 Acknowledges Block #1 TEXT Block #3 PAD S5066-006 BCC Accumulation PAD SYN...SYN STX PAD SYN...SYN ACK1 PAD ITB BCC SYN SYN BCC Accumulation PAD SYN...
6100 BSC Concepts and Context The ETB character (End Transmission Block) has a value of 17 hexadecimal in ASCII, 26 hexadecimal in EBCDIC. It completes a block and turns the line around, permitting the remote station to reply. As shown in the figure, ETB is permitted at the end of the heading or of a block of text. In each case, the block check sequence immediately follows the ETB; the subsequent block begins with STX, which starts a new block check accumulation.
6100 BSC Concepts and Context The ETB and ITB characters are visible to the application. The sending application includes them in its output buffer; the receiving application finds them in its input buffer. The block check characters do not appear in any application buffer. The blocks of a message need not be of uniform length. SYN WITHIN THE MESSAGE. This section has already described the SYN pattern that starts a transmission. There are other situations in which a station transmits SYN characters.
6100 BSC Concepts and Context TRANSPARENT TEXT. An application might want to include as message data a bit pattern corresponding to a BSC control character. For example, a message could contain numerical results of computations, an object file, or digitized graphic material. In such a case, a sequence of bits intended as data might coincidentally match the value of a character like STX or ITB. To provide for these situations, BSC has a feature called transparent text mode.
6100 BSC Concepts and Context BCC Accumulation PAD SYN...SYN DLE STX TEXT DLE ETX BCC PAD 1 Application-Supplied BCC Accumulation PAD SYN...SYN SOH DATA DLE STX TEXT BSC-Supplied DLE ETX BCC PAD 1 1 PAD SYN...SYN SOH DATA STX ETB BCC PAD TEXT PAD SYN...SYN DLE STX TEXT DLE ETB BCC PAD PAD STX TEXT ETX BCC PAD This is the only transparent block in the message 2 PAD SYN...
6100 BSC Concepts and Context The meaning of DLE to the receiver is "The next character is not transparent; it is really a control character." In processing incoming transparent text, BSC ignores any control character not preceded by DLE. The receiver interprets DLE DLE to mean "Ignore the first DLE, and treat the second as data." The receiver strips DLE from the block except where it precedes STX or is preceded by DLE; in these two cases, DLE is delivered to the application.
6100 BSC Concepts and Context Data Link Control Procedures The orderly exchange of data relies not only on well-defined message formats, but also on well-defined data link control procedures. The following procedures are part of the BSC protocol: • Circuit assurance. Lets stations on a dialup line identify themselves to one another. • Bidding for the line. Lets a station obtain the right to transmit a series of blocks or messages. • Data transfer.
6100 BSC Concepts and Context Application-Supplied BSC-Supplied Calling Station: PAD SYN...SYN ID ENQ PAD 2–15 Characters Called Station: PAD SYN...SYN ID ACK0 PAD 2–15 Characters S5066-008 Figure 1-8. ID Exchange The called station normally replies: SYN SYN ... SYN id ACK 0 PAD The underscore shows the contents of the application buffer. This sequence identifies the called station and says that the station is ready to continue.
6100 BSC Concepts and Context If the called station is not ready to continue, it can send one of the following replies: SYN SYN ... SYN id NAK PAD (The station is not ready to receive.) SYN SYN ... SYN WACK PAD (The station is temporarily not ready to receive.) The underscore shows the contents of the application buffer. NAK is 15 hexadecimal in ASCII, 3D hexadecimal in EBCDIC.
6100 BSC Concepts and Context BIDDING FOR THE LINE. If a station wishes to transmit data to the other station, it must first bid to gain access to the line. Figure 1-9 illustrates the bidding sequence. BSC-Supplied (see text) Transmitting Station: PAD SYN...SYN ENQ PAD Receiving Station: PAD SYN...SYN ACK0 PAD S5066-009 Figure 1-9. Bidding for the Line As the figure shows, the station that wishes to send data first transmits the following: SYN SYN ...
6100 BSC Concepts and Context If a station is not ready to receive, it can send a NAK or WACK reply, instead of ACK 0. In that case, the bidder can try again later or disconnect the line with DLE EOT. Your application may not send a NAK or a WACK in response to a bid. BSC sends a NAK for you in the case of certain error conditions; it does not send a WACK during line bidding, but reports to you if a WACK is received.
6100 BSC Concepts and Context DATA TRANSFER. The general protocol for data transfer is shown in Figure 1-10. The station that owns the line transmits a message or a block, conforming to one of the formats described earlier in this section. The other station responds, and the dialogue proceeds. After transmitting all of its messages, the station gives up the line (see "Relinquishing the Line").
6100 BSC Concepts and Context Some special conditions, and some applications, call for variations on the general protocol. The means for accomplishing such variations are described as "Data Transfer Variations," below. RELINQUISHING THE LINE. When a station has completed its transmissions, it issues the following sequence: SYN SYN ... SYN EOT PAD The application does not supply this sequence. Rather, BSC sends it automatically when a READ request follows a series of WRITEs.
6100 BSC Concepts and Context Station A P S S E P A Y ... Y N A D N N QD P S A Y ... D N Line Bid SS Y T TEXT NX P S S EP A Y ... Y O A D N N TD ... Data Transfer ... A P S S P C ... A Y Y A K D N N D 0 Station B P S A Y ... D N A S P C Y A K N D 0 Line Bid A C K n P A D ... Data ... P S S E P A Y ... Y N A D N N Q D P S S S A Y ... Y T TE D N N X Station B refuses the chance to bid A P S S P C A Y ... ... Y A K D N N D n Station A P S S E P A Y ... Y O A D N N TD P S A Y ...
6100 BSC Concepts and Context DISCONNECTING THE LINE. To sever a dialup connection, a station issues the following sequence: SYN SYN ... SYN DLE EOT PAD Normally, this sequence occurs when all data transfers are complete. You can also use it at other times to terminate the session, for example, if an error condition makes it useless to proceed. The application makes a CONTROL request to send the disconnect sequence; it does not supply the sequence in its output buffer.
6100 BSC Concepts and Context An arriving NAK completes the request that sent the TTD. The application can repeat the TTD as often as the other station allows, i.e., as often as its retry count permits. Then it must either send its next block or relinquish the line. Forward Abort. If after a TTD sequence a station sends an EOT as its next transmission, the EOT means "I can't send more data. I'm too busy, or an error has occurred." Without the preceding TTD, the EOT would be a normal end of transmission.
6100 BSC Concepts and Context Normal End of Transmission Transmitting Station: PAD SYN...SYN ENQ PAD PAD SYN...SYN STX TEXT ETX BCC PAD PAD SYN...SYN EOT PAD Receiving Station: PAD SYN...SYN PAD PAD SYN...SYN ACK1 PAD Forward Abort TTD Transmitting Station: PAD SYN...SYN STX TEXT ETX BCC PAD PAD SYN...SYN STX ENQ PAD PAD SYN...SYN EOT PAD Receiving Station: PAD SYN...SYN ACK1 PAD PAD SYN...SYN NAK PAD Application-Supplied BSC-Supplied S5066-012 Figure 1-12.
6100 BSC Concepts and Context Enquiry (ENQ). The ENQ character has two special functions, apart from the line bid and TTD sequences: • If BSC receives a garbled reply to a message block, or if it doesn't receive a reply at all within the expected time, it uses the ENQ sequence to request another reply. (The expected time is 2.7 seconds for a primary station, 3 seconds for a secondary station.) BSC sends the sequence as often as the retry count allows; this activity is transparent to the application.
6100 BSC Concepts and Context Transmitting Station: PAD SYN...SYN STX TEXT ETB BCC PAD PAD SYN...SYN ENQ PAD PAD SYN...SYN STX TEXT ETX BCC PAD "Please repeat that reply" Receiving Station: PAD SYN...SYN ACK0 PAD PAD SYN...SYN ACK0 PAD Application-Supplied BSC-Supplied S5066-013 Figure 1-13. "Please repeat that reply" Transmitting Station: PAD SYN...SYN STX TEXT ENQ PAD PAD SYN...SYN STX TEXT ETX BCC PAD Receiving Station: PAD SYN...SYN NAK PAD PAD SYN...
6100 BSC Concepts and Context Negative Acknowledgement (NAK). Except in the context of circuit assurance, BSC sends NAK acknowledgements whenever they are needed. There is no application request to send a negative acknowledgement. During circuit assurance, the application puts the NAK in its buffer, if needed. Figure 1-15 shows several uses of NAK. BSC sends NAK as a reply in any of the following cases: • It receives a block that contains an error.
Figure 1-15. BSC-Supplied PAD SYN...SYN STX TEX ETB BCC PAD PAD SYN...SYN ID ENQ PAD Circuit Assurance TEXT Data Transfer PAD SYN...SYN STX Data Transfer Resumes PAD SYN...SYN NAK PAD Application-Supplied TTD NAK PAD Station Not Ready PAD SYN...SYN PAD SYN...SYN STX ENQ PAD Data Transfer PAD SYN...SYN ENQ PAD Line Bid Error in ID PAD SYN...SYN NAK PAD BCC Error PAD SYN...SYN NAK PAD PAD SYN...
6100 BSC Concepts and Context Wait-Before-Transmit Positive Acknowledgement (WACK). A station sends WACK as a reply if it is temporarily unable to receive. WACK is an acceptable response to an ID sequence for circuit assurance, to a line bid, or to a message block (including a heading block). It must be issued within two seconds after receiving the transmission.
Figure 1-16. TEXT ETB BCC PAD Use of WACK TEXT ETB BCC PAD Figure 1-17. BSC-Supplied Application-Supplied Station B Station A transmits a block, PAD SYN...SYN STX BSC-Supplied Application-Supplied PAD SYN...SYN STX RVI sends RVI, PAD SYN...SYN PAD TEXT ETX BCC PAD PAD SYN...SYN ACK0 PAD S5066-017 and bids for the line. PAD S5066-016 PAD SYN...SYN ENQ and gives up the line. PAD SYN...SYN EOT PAD Next Block PAD SYN...
6100 BSC Concepts and Context If a station receives RVI and ignores it, treating it like ACK 0 or ACK 1, the replying station is not allowed to repeat the RVI. A second RVI is allowed only where the first was garbled or not received, i.e., where the response to RVI was ENQ, "Please repeat that reply." RVI is a positive acknowledgement; the last message block was received without error. Conversational Mode.
6100 BSC Concepts and Context With the multileaving option, stations can exchange conversational replies without restriction. Conceivably, two stations could exchange text replies exclusively. Figure 1-19 illustrates this behavior. A station that receives a conversational reply can assume that its message was received without error. If the message had an error, the station that received it would send an ENQ in reply, and wait. A conversational reply is allowed only if the message was received without error.
6100 BSC Concepts and Context Transmitting Station: PAD SYN...SYN ENQ PAD PAD SYN...SYN STX TEXT ETX BCC PAD PAD SYN...SYN ACK1 PAD Acknowledgement 1 Receiving Station: PAD SYN...SYN ACK0 PAD PAD SYN...SYN STX TEXT ETX BCC PAD Conversational Reply Application-Supplied BSC-Supplied Legend 1 With 6100 BSC, the transmitting station can also send a message at this point.
6100 BSC Concepts and Context Error Control The following means of error control have been mentioned in this section: • Block check characters (BCC) • Timeouts • Negative acknowledgements and sequences requesting retransmission of a block (NAK) or reply (ENQ) • Means for aborting a transmitted block (ENQ) or a series of transmissions (TTD followed by EOT) • Means for indicating inability to send or receive data (TTD, WACK) All of these topics, except the timeouts, were described in some detail.
6100 BSC Concepts and Context WAIT FOR ACKNOWLEDGEMENT. After transmitting a message, a line bid, or another sequence, the sending station expects an acknowledgement within a certain time. The time is 2.7 seconds for a primary station, 3 seconds for a secondary station. If no acknowledgement arrives or if the acknowledgement is garbled, BSC sends an ENQ sequence to mean "Please repeat that reply.
6100 BSC Concepts and Context If a station receives a block without error but isn't ready to receive the next one, the application sends a WACK reply within two seconds. The application CONTROL request can perform this function. If the application fails to send a WACK, the other station can send an ENQ to request another reply.
6100 BSC Concepts and Context NOTE Remember that any parameter you set for the local station must be consistent with the operation of the remote station. In some cases, the settings must match; for example, the block checking option (LRC or CRC16) must be the same on both sides of the link. In some cases, the settings must be complementary; for example, if one station is identified as a primary, the other should be identified as a secondary station. LINE AND MODEM CONTROL.
6100 BSC Concepts and Context The value of BSCCONNECTTO can range from 0 to 32767, and expresses the timeout interval in 10-ms units. If the value is 0, BSC waits indefinitely for DSR. In general, if the line is leased, the value can be quite small, because the modem keeps DSR raised whenever power is on. In the case of a switched line with the LIU on the receiving end, the value should reflect how long it will take for a call to come in.
6100 BSC Concepts and Context BSCPPSW, BSCPPNSW. This parameter specifies whether the line is switched or leased. BSCPPSW stands for "point-to-point switched." BSCPPNSW stands for "point-to-point nonswitched," and is the default. The major differences between these options have to do with connection. A nonswitched (leased) line is always connected; the DTR signal is always on. Thus, parameters and functions related to connection are not used or have only nominal effect. TRANSMISSION CONTROL.
6100 BSC Concepts and Context and must be in the range 0 through 32767. means no blocking will occur. The default value, 0, BSCITBSIZE has no meaning for normal text. Nor does it come into play when BSC receives transparent text. The message formats and protocol associated with transparent text were described in this section, under the heading "Transparent Text." BSCSYNCS. This parameter specifies the number of SYN characters to start each transmission.
6100 BSC Concepts and Context You must use these values instead of the normal ASCII sequences for ACK 0 and WACK, because BSC translates the output buffer character by character. The ASCII sequences--for instance, 10 30 for ACK 0--would not produce the correct EBCDIC control sequences. ERROR HANDLING. handles errors: The following parameters affect how BSC BSCRETRIES. This parameter specifies how often BSC repeats an operation that has failed.
6100 BSC Concepts and Context perform end-to-end recovery.
SECTION 2 6100 BSC LINK AND STATION MANAGEMENT This section describes two important aspects of BSC operation: • The six major states through which a station moves, and the events that cause transitions between states. Some application requests have different meanings in different states, and error messages can indicate unexpected state transitions. • The modem signals BSC uses, and the events that cause them to change.
6100 BSC Link and Station Management LINE STATES AND TRANSITIONS 6100 BSC is realized as a "state machine." At a given time, a station is in one of six major states. Application requests and arriving data are "events" that can cause state transitions. Only certain events are allowed in each state; for example, you can't send data if the station is disconnected, and you can't change line parameters unless the station is disconnected. Figure 2-1 presents a simplified view of BSC states and transitions.
6100 BSC Link and Station Management DISCONNECTED If BSCIDEXCH applies: • CONTROL CONNECT • Initial READ, WRITE, WRITEREAD If BSCIDEXCH does not apply: • CONTROL CONNECT • Initial READ, WRITE, WRITEREAD CIRCUIT ASSURANCE CONTROL DISCONNECT • Receive DLE EOT • Lose DSR • CMI STOP • Equipment Malfunction • CONTROL Make line bid (WRITE, WRITEREAD) Accept line bid (READ) EOT EOT, Retry errors (various) READ Receive ACK to conv.
6100 BSC Link and Station Management DISCONNECTED State A station is in DISCONNECTED state if the LIU has been downloaded but a connection has not been established. Perhaps an earlier connection was lost, or there is temporarily no caller on a dialup line. BSC may be waiting for the application to request a connection, or it may be trying to make a connection--waiting for DSR to appear after raising DTR. TRANSITIONS TO DISCONNECTED STATE. The station begins operation in DISCONNECTED state.
6100 BSC Link and Station Management the station, bid for the line, send the first message, and read the response; in this case, the state goes from DISCONNECTED to CONTROL to WRITE to READ.
6100 BSC Link and Station Management ----------------------------------------------------------------| | | Request Status Code Description New State | | | | WRITEREAD | | If BSCIDEXCH applies: | | 0 Normal completion CONTROL | | 170 Bad ID, no ID CIRCUIT ASS.
00 BSC Link and Station Management REQUESTS AND FUNCTIONS APPLICABLE TO DISCONNECTED STATE. The following requests are permitted in DISCONNECTED state. Some requests have different functions when the line is in other states. For complete descriptions of the requests, see Section 3. ----------------------------------------------------------------| | | SET CONFIGURATION, to change line parameters. This request | | is permitted only in DISCONNECTED state. It does not cause | | a change of state.
6100 BSC Link and Station Management CIRCUIT ASSURANCE State A station is in CIRCUIT ASSURANCE state if the line is switched, a connection exists, and ID exchange is required but hasn't been accomplished. (You express the requirement for ID exchange with the BSCIDEXCH line parameter.) TRANSITIONS TO CIRCUIT ASSURANCE STATE. All transitions to CIRCUIT ASSURANCE state are from DISCONNECTED state.
6100 BSC Link and Station Management ----------------------------------------------------------------| | | | | Original State: CIRCUIT ASSURANCE | | | | Request Status Code Description New State | | | | READ 140 Modem error DISCONNECTED | | 161 6100 error DISCONNECTED | | 164 DLE EOT received DISCONNECTED | | 190 6100 error DISCONNECTED | | other CIRCUIT ASS.
6100 BSC Link and Station Management REQUESTS AND FUNCTIONS APPLICABLE TO CIRCUIT ASSURANCE STATE. The following requests are permitted in CIRCUIT ASSURANCE state. Some requests have different functions when the line is in other states. For complete descriptions of the requests, see Section 3. ----------------------------------------------------------------| | | FETCH CONFIGURATION, to retrieve line parameters. You | | can find out the values of line parameters, but you aren't | | allowed to change them.
6100 BSC Link and Station Management CONTROL State A station is in CONTROL state if a connection exists, ID exchange is complete if required, and neither station owns the line. It is in this state that line bidding occurs. TRANSITIONS TO CONTROL STATE. The following events cause transitions to CONTROL state from other states: • The application makes a CONTROL request to connect the line. If the line is leased or does not require ID exchange, the state changes from DISCONNECTED to CONTROL.
6100 BSC Link and Station Management TRANSITIONS FROM CONTROL STATE. The following events cause transitions from CONTROL STATE to other states: • The application makes a request that results in a successful line bid. For example, it makes a WRITE request to bid for the line and send the first message; the state changes from CONTROL to WRITE. Alternatively, it makes a READ request to accept a bid and receive the first message; the state changes from CONTROL to READ.
6100 BSC Link and Station Management ----------------------------------------------------------------| | | Request Status Code Description New State | | | | WRITEREAD 0 Normal completion: WRITE if ACK;| | ACK or text READ if text | | 140 Modem error DISCONNECTED | | 161 6100 error DISCONNECTED | | 162 Timeout WRITE or | | CONTROL | | 164 DLE EOT received DISCONNECTED | | 165 RVI received WRITE | | 166 ENQ reply to bid CONTROL if | | primary, READ| | if secondary | | 173 Bad BCC or other CONTROL if | | error
6100 BSC Link and Station Management REQUESTS AND FUNCTIONS APPLICABLE TO CONTROL STATE. The following requests are permitted in CONTROL state. Some requests have different functions when the line is in other states. For complete descriptions of the requests, see Section 3. ----------------------------------------------------------------| | | FETCH CONFIGURATION, to retrieve line parameters. You can | | find out the values of line parameters, but you aren't | | allowed to change them in this state.
6100 BSC Link and Station Management ----------------------------------------------------------------| | | cancelling the READ, the new state is CONTROL; if a bid has | | occurred, the READ isn't cancelled and the new state is READ.
6100 BSC Link and Station Management READ State A station is in READ state when reading text, and whenever it owes an acknowledgement to the other station, i.e., between READ requests. TRANSITIONS TO READ STATE. The following requests cause a station to be in READ state: • The application makes a READ request to accept a line bid and read the first message. The state changes from CONTROL to READ. During the series of READ requests, the receiving station stays in READ state most of the time.
6100 BSC Link and Station Management ----------------------------------------------------------------| | | Original State: READ | | | | Request Status Code Description New State | | | | READ 140 Modem error DISCONNECTED | | 161 6100 error DISCONNECTED | | 162 Timeout CONTROL | | 163 EOT received CONTROL | | 164 DLE EOT received DISCONNECTED | | 166 ENQ received CONTROL | | 172 Format error in CONTROL | | received data | | 173 Bad BCC or other CONTROL | | data error | | 177 Received block CONTROL | | too lar
6100 BSC Link and Station Management REQUESTS AND FUNCTIONS APPLICABLE TO READ STATE. The following requests are permitted in READ state. Some requests have different functions when the line is in other states. For complete descriptions of the requests, see Section 3. ----------------------------------------------------------------| | | FETCH CONFIGURATION, to retrieve line parameters. You can | | find out the values of line parameters, but you aren't | | allowed to change them in this state.
6100 BSC Link and Station Management WRITE State A station is in WRITE state when writing data, and whenever it may write data, i.e., between WRITE requests or when the other station allows a conversational reply. TRANSITIONS TO WRITE STATE. to be in WRITE state: The following events cause a station • The application makes a WRITE request to make a line bid and send the first message. During data transfer, the station remains in WRITE state most of the time.
6100 BSC Link and Station Management ----------------------------------------------------------------| | | Original State: WRITE | | | | Request Status Code Description New State | | | | WRITE 140 Modem error DISCONNECTED | | 161 6100 error DISCONNECTED | | 163 EOT reply to block CONTROL | | 164 DLE EOT received DISCONNECTED | | 190 6100 error DISCONNECTED | | other WRITE | | READ 0 Normal completion READ | | 140 Modem error DISCONNECTED | | 161 6100 error DISCONNECTED | | 162 Timeout CONTROL | | 163 EOT re
6100 BSC Link and Station Management REQUESTS AND FUNCTIONS APPLICABLE TO WRITE STATE. The following requests are permitted in WRITE state. Some requests have different functions when the line is in other states. For complete descriptions of the requests, see Section 3. ----------------------------------------------------------------| | | | | FETCH CONFIGURATION, to retrieve line parameters. You can | | find out the values of line parameters, but you can't | | change them in this state.
6100 BSC Link and Station Management MULTILEAVING State A station can be in MULTILEAVING state if you did not specify BSCPTPT as a SYSGEN parameter (see Section 1). The state is required for HASP operation but not restricted to use with EXCHANGE. In MULTILEAVING state--sometimes called full conversational mode--the application has almost complete control over the line.
6100 BSC Link and Station Management ----------------------------------------------------------------| | | | | Original State: MULTILEAVING | | | | Request Status Code Description New State | | | | WRITEREAD 0 Normal completion MULTILEAVING | | 140 Modem error DISCONNECTED | | 161 6100 error DISCONNECTED | | 162 Timeout MULTILEAVING | | 164 DLE EOT received DISCONNECTED | | 173 Bad BCC or other MULTILEAVING | | data error | | 190 6100 error DISCONNECTED | | | | | --------------------------------------------
6100 BSC Link and Station Management MODEM SIGNALS AND THEIR USE 6100 BSC uses the following modem signals: RS232 Signal Mnemonic Function Pin AA AB BA BB DB DD DA Protective ground Signal reference (signal ground) Transmit data (TxD) Receive data (RxD) Transmit clock (TxC) Receive clock (RxC) Terminal-supplied transmit clock (TxC0) 1 7 2 3 15 17 24 CA CB CC CF CD Request to send Clear to send Data set ready Data carrier detect Data terminal ready 4 5 6 8 20 (RTS) (CTS) (DSR) (DCD) (DTR) The RS232
6100 BSC Link and Station Management Data Terminal Ready (DTR) The use of this signal depends on whether the line is switched or leased. If the line is leased, DTR is asserted as part of the line configuration procedure. If you specified AUTOCONF in the SYSGEN entry for the line, CP6100 sends the line parameters to the LIU after the line is downloaded. (See Section 3 of the CP6100 I/O Process Programming Manual for a complete description.
6100 BSC Link and Station Management several times above, BSC expects DSR to appear within a certain interval (BSCCONNECTO). Thereafter, DSR must stay on throughout the connection, and it may stay on even if the application makes a disconnect request. BSC doesn't monitor DSR between requests, but if it drops during a request, the request completes with a modem error. If the line is switched, the modem asserts DSR in response to DTR.
6100 BSC Link and Station Management ----------------------------------------------------------------| | | | | Request Line Action | | | | | | READ (ACK option) ACK -----> | | <------ msg | | | | READ (RVI option) RVI -----> | | <------ msg | | | | READ (with line in EOT -----> | | WRITE state) <------ msg | | | | WRITE msg -----> | | <------ ACK | | | | WRITEREAD msg -----> | | <------ msg | | | | CONTROL (TTD option) TTD -----> | | <------ NAK | | | | CONTROL (WACK option) WACK ----> | | <------ ENQ | | |
6100 BSC Link and Station Management On a half duplex line, BSC lowers RTS as soon as the write is complete, for instance, right after transmitting the ACK as part of the READ request. Clear to Send (CTS) BSC waits for this signal before starting to transmit, and expects the signal to stay on throughout the transmission. If CTS drops during a transmission, the transmission stops and a modem error (status code 140) is reported; the status detail field tells which signal was lost.
6100 BSC Link and Station Management Receive Clock (RxC) This signal is always used to clock incoming data. Transmit Clock (TxC) If the SYSGEN entry indicates that the modem supplies the transmit clock--that is, if you didn't specify the BSCINTERNALCLK parameter--this signal is used to clock transmit data, and the modem determines the speed.
SECTION 3 WRITING APPLICATIONS THAT USE 6100 BSC An application that communicates with a remote station on a BSC line must perform several tasks to ensure successful communication. These tasks are (in order): • opening the line • setting line parameters (optional) • establishing connection • bidding for the line • transferring data • relinquishing the line • disconnecting the line • closing the line ) ) ) ) ) This series of actions can occur many times during a connection.
Writing Applications that Use 6100 BSC Opening the Line Any application that wants to use the line must first open it. You accomplish this task with a call to the GUARDIAN OPEN procedure, described in Volume 1 of the GUARDIAN Operating System Programming Manual. In the OPEN call, you specify several important parameters.
Writing Applications that Use 6100 BSC There may be a reason for multiple OPENs, despite the rule against concurrent requests. For example, you might want to use one OPEN for reading and writing, and another to fetch and present statistics. This use of OPENs achieves not concurrency, but a separation of function: an AWAITIO call with a given file number completes a specific class of requests. Normally, multiple OPENs are issued by the same process.
Writing Applications that Use 6100 BSC Setting Line Parameters Most applications don't have to set the line configuration parameters. Rather, you define the parameters in SYSGEN, and include AUTOCONF among them. (AUTOCONF applies by default to BSC, so you don't have to state it explicitly.) With AUTOCONF, configuration occurs whenever the line is downloaded. If at some point all openers close the line, the next OPEN call sets the new configuration.
Writing Applications that Use 6100 BSC You can change only two parameters after the line is connected. By making a WRITEREAD call with the SETMODE request, you can change the retry count for the line or the block length for transparent text. A change you make with the SETMODE request lasts until the next download, or until you make another SETMODE request, or until CMI or the application makes a SET CONFIGURATION request.
Writing Applications that Use 6100 BSC Starting the Link Starting up the link consists of one or two tasks, depending on whether the stations practice ID exchange. The first of the two tasks is to connect the link. If the line is switched, connection implies a physical and a logical action: a telephone call is established between the two stations, and the line state changes from DISCONNECTED to CIRCUIT ASSURANCE or CONTROL.
Writing Applications that Use 6100 BSC ----------------------------------------------------------------| | | | | Called Station Calling Station | | | | / | | READ | | | request | \ | | | <------ ID ENQ | WRITEREAD | | \ | request | | / | | | WRITEREAD | ID ACK 0 ----> | | | request | / | | | \ | | \ <------ msg | WRITE request | | | | | | The underscore shows the information applications | | supply and receive.
Writing Applications that Use 6100 BSC Bidding for the Line (or Accepting a Bid) A station that wishes to transmit a series of blocks or messages must first bid for the line, as described in Section 1. The line must be in CONTROL state for bidding to occur. Figure 3-3 illustrates a typical bidding transaction. To make a bid, the application issues a WRITE or WRITEREAD request.
Writing Applications that Use 6100 BSC ----------------------------------------------------------------| | | | | Local Station Remote Station | | | | \ | | | READ | | | request | | / ENQ ---------> | | | WRITE | / | | request | \ | | | <-------- ACK 0 | READ | | | | request | | | msg ---------> | | | | / | | | \ | | \ <-------- ACK 1 | READ | | / | request | | WRITE | msg ---------> | | | request | / | | | | | \ | | | | | | The underscore shows the information applications | | supply and receive.
Writing Applications that Use 6100 BSC Sometimes both stations bid for the line at the same time. If a secondary station makes a bid and receives another bid in response, the WRITE or WRITEREAD request completes with error 166. An application that receives this error should yield the line to the primary station--both to be consistent with a protocol convention and to end an otherwise wasteful stalemate.
Writing Applications that Use 6100 BSC ----------------------------------------------------------------| | | | | Local Station (Prim.) Remote Station (Sec.
Writing Applications that Use 6100 BSC Transferring Data Once a line bid has occurred, the stations begin to exchange data. Usually the transmitting station makes a series of WRITE requests, as in Figure 3-5. Each request sends a message or a block, and awaits an acknowledgement. A WRITE request completes when the acknowledgement arrives. Notice that in the figure, the first WRITE request includes the line bid. To acknowledge a block and receive the next one, the receiving station makes a READ request.
Writing Applications that Use 6100 BSC ----------------------------------------------------------------| | | | | Local Station Remote Station | | | | \ | | / ENQ ---------> | READ | | WRITE | | request | | request | <---------- ACK 0 | | | | | | | | msg ---------> | | | | / | | | <---------- ACK 1 \ | | \ | READ | | / | request | | WRITE | msg ---------> | | | request | / | | | <---------- ACK 0 \ | | \ | READ | | WRITE . . requests | | requests . . | | . .
Writing Applications that Use 6100 BSC If the receiving station is temporarily unable to receive data, it can make a CONTROL request with the WACK option. (See the discussion of WACK in Section 1). The request sends a WACK reply and awaits a response, normally ENQ. The application can make repeated CONTROL WACK requests, then finally make a READ request when it is ready to receive data. If the receiving station has an urgent message for the other station, it can make a READ request with the RVI option.
Writing Applications that Use 6100 BSC To allow a conversational reply instead of an acknowledgement, the application makes a WRITEREAD request, instead of a WRITE. (In this case, the transmitted block normally ends with ETX, although 6100 BSC does not enforce that restriction.) To make the reply, the receiving station makes a WRITEREAD request. To acknowledge the block instead of making a conversational reply, the station makes a READ request.
Writing Applications that Use 6100 BSC ----------------------------------------------------------------| | | | | Local Station Remote Station | | | | WRITE . \ | | requests . <-------- ACK n | READ | | .
Writing Applications that Use 6100 BSC Relinquishing the Line After completing a series of transmissions, a station must relinquish the line and return it to CONTROL state. To accomplish this task, the transmitting station makes a READ request, instead of WRITE or WRITEREAD. This request sends an EOT sequence and awaits a line bid.
Writing Applications that Use 6100 BSC ----------------------------------------------------------------| | | Local Station Remote Station | | | | a) / | READ request | | READ | EOT ---------> | (completes with | | request | / status 163--EOT) | | | \ | | (turns | <--------- ENQ | WRITE | | line | | request | | around, | ACK 0 -------> | (makes bid, sends | | accepts | | first message) | | bid) \ <--------- msg | | | / | | | READ | ACK 1 -------> | | | request | / | | | | | | b) / | | READ | EOT ---------> |
Writing Applications that Use 6100 BSC Shutting Down the Link When all applications have closed the line, CP6100 disconnects it, unless the parameter NOAUTOSTOP has been defined for the line. A disconnect implies that if the line is switched, the station sends the sequence DLE EOT and "hangs up the telephone" by dropping DTR. The line state changes to DISCONNECTED, whether the line is switched or leased.
Writing Applications that Use 6100 BSC Recovering from Errors There are two ways a BSC application finds out about errors: • A file system call completes with a non-zero condition code. • A WRITEREAD call completes with a condition code of zero, but the status field in the application buffer contains an error code. The status detail field in the buffer gives more information about the error.
Writing Applications that Use 6100 BSC The setting of the BSCNONSTOPON parameter can have a major impact on error recovery. If BSCNONSTOPON applies and a path switch occurs in the 6100 subsystem, the protocol state is retained, i.e., it doesn't become undefined. The application can retry its request, normally with no fear of loss or duplication of data. There are several considerations that apply to retries: • The retry must have the same request ID as the original request.
Writing Applications that Use 6100 BSC error by giving the station more chances to succeed in each operation. • The FETCH STATISTICS request retrieves line quality information and other data useful for evaluating problems. • The ABORT request cancels an active request, unless that request is FETCH STATISTICS or FETCH CONFIGURATION. (Review the list of requests in Figure 3-1.) ABORT does not undo any actions, but completes the request abruptly with an error message.
Writing Applications that Use 6100 BSC REQUESTS AND RESPONSES The rest of this section describes the requests an application can issue, and the responses BSC makes to the application. You encode a request to BSC in the WRITEREAD buffer. Figure 3-9 depicts the buffer format. The fields are defined as follows: Function. This byte contains a number representing one request function. For example, the number 1 represents the SET CONFIGURATION function. Modifier.
Writing Applications that Use 6100 BSC Outgoing Buffer Format (Request) STRING INTEGER STRING Function, like send text Modifier to function Incoming Buffer Format (Reply) Response, same as function Status, ok or error code Request ID, unique for all pending requests 1≤ reqid ≤ 32767 Request ID, same as in request TextOut, size of text field in bytes Status Detail TextIn, number of bytes expected in response TextIn, number of bytes received Text, depends on function and application Text, dep
Writing Applications that Use 6100 BSC When the request completes, the buffer has the same structure as before, but some of the fields have different meanings: Response. This byte contains the same number that denoted the function in the request. For example, the number 1 occurs in the response to SET CONFIGURATION. Status. This byte contains a code representing normal completion or an error. For example, the number 0 indicates a normal completion; the number 140 indicates a modem error. Request ID.
Writing Applications that Use 6100 BSC Figure 3-10 lists the requests and responses in numerical order, including requests issued only by CP6100. (Those requests are included in the list because you might see them in a TRACE listing.
Writing Applications that Use 6100 BSC ABORT Request and Response The ABORT request stops any request except FETCH STATISTICS or FETCH CONFIGURATION. It doesn't undo any actions; nor does it notify the other station. Rather, it stops fulfilling the request and completes it with a status code of 122 (request aborted). The application receives two completions: one from the ABORT request, and the other from the aborted request.
Writing Applications that Use 6100 BSC In short, aborting a request is a drastic action to take. useful mainly in two cases: It is • A request is taking so long you think it might never complete. For instance, if a line has no connect timeout and a CONTROL CONNECT request is taking too long, you might abort the request in order to issue another one (like SET CONFIGURATION). • A path switch occurs during the request. For instance, you issue a READ request, and the call completes with error 210.
Writing Applications that Use 6100 BSC The response buffer format is: Function := 69 Status := 0 if the abort occurred, or if there was no request to abort; otherwise, a code for the error that occurred (e.g., an invalid parameter) Request ID := The same as in the ABORT request Detail := A status detail code, e.g.
Writing Applications that Use 6100 BSC CONTROL Request and Response The CONTROL request can be used for any of the following functions: • To CONNECT the line by raising DTR and optionally waiting for DSR. • To DISCONNECT the line by dropping DTR and optionally waiting for DSR to drop. • To send a TTD sequence, indicating unreadiness to send data. • To send a WACK sequence, indicating unreadiness to receive data.
Writing Applications that Use 6100 BSC CONNECT. The CONTROL CONNECT request explicitly connects the line. It raises DTR and may or may not wait for DSR, depending on the value in the modifier field. If it waits for DSR, the value of BSCCONNECTTO (a line parameter) determines the interval. This request makes sense only when the line is in DISCONNECTED state. When the request completes, the state is CIRCUIT ASSURANCE if ID exchange will ensue; otherwise, the state is CONTROL.
Writing Applications that Use 6100 BSC DISCONNECT. The CONTROL DISCONNECT request explicitly disconnects the line. If the line is leased, the request does not alter any signals; it completes right away. If the line is switched, the request sends a DLE EOT sequence to the other station, then drops DTR, and optionally waits for DSR. If it waits, the value of BSCDISCONNECTTO (a line parameter) determines the interval. This request makes sense when the line is in any state except DISCONNECTED.
Writing Applications that Use 6100 BSC SEND TTD. This request sends a TTD sequence to the remote station, then waits for a NAK reply. TTD indicates a temporary inability to transmit data, as described in Section 1 of this book. It makes sense only in WRITE state, and only if this is the transmitting station. When the request completes, the line is in WRITE state, just as before.
Writing Applications that Use 6100 BSC SEND WACK. This request sends a WACK reply to the remote station, then waits for an ENQ response. WACK indicates a temporary inability to receive data, as described in Section 1 of this book. It makes sense only in READ state, i.e., if this is the receiving station during a data transfer. When the request completes, the line is in READ state, ready for a READ to be issued.
Writing Applications that Use 6100 BSC SEND EOT. This request sends an EOT sequence to the remote station. It is used either to reset the line after a read error, or to decline the chance to bid for the line, as described in Section 1. This request doesn't monitor the line for a reply, and should therefore not be used as the normal end to series of transmissions; READ should be used for that purpose, as described in "Relinquishing the Line," in this section.
Writing Applications that Use 6100 BSC FETCH CONFIGURATION Request and Response The FETCH CONFIGURATION request retrieves the current values of the line configuration parameters (as stored in the LIU) or the user-defined translate tables. For information about the parameters, see "Line Configuration Options" in Section 1; the names that appear in the list below are the names you use in the SYSGEN entry. For information about the translate tables, see "SET CONFIGURATION," in this section.
Writing Applications that Use 6100 BSC CONFIGURATION BLOCK FORMAT. block is: Parameter The structure of the configuration Byte Length Offset, (Bytes) Description BSCFULL or BSCHALF 0 1 0 = full duplex 1 = half duplex BSCPPSW or BSCPPNS 1 1 0 = switched 1 = non-switched Reserved 2 3 1 1 0 0 BSCINTERNALCLK 4 1 2 = modem clock 4 = LIU clock BSCBAUD 5 1 BSCCONNECTTO 6 2 0 = no timeout n = value in .01 seconds BSCDISCONNECTTO 8 2 0 = no timeout n = value in .
Writing Applications that Use 6100 BSC BSCREADTO 14 2 Value in .01 seconds BSCSECONDARY 16 1 0 = primary 1 = secondary BSCIDEXCH 17 1 0 = no ID exchange 1 = ID exchange BSCRETRIES 18 2 Number of retries BSCITBSIZE 20 2 Length in bytes TRANSLATE TABLE FORMAT. A translate table consists of 512 text entries: an ASCII to EBCDIC table 256 bytes long, followed by an EBCDIC to ASCII table 256 bytes long. For more information, see SET CONFIGURATION, later in this section.
Writing Applications that Use 6100 BSC FETCH STATISTICS Request and Response The FETCH STATISTICS request retrieves a block of statistics pertaining to line quality, counts of various kinds of frames and errors. You can make this request at any time, without affecting the line state; it is most useful during error handling. THIS REQUEST PROVIDES MUCH MORE INFORMATION THAN THE CMI STATUS COMMAND.
Writing Applications that Use 6100 BSC The response buffer format is: Response := 5 Status := 0 if the text field contains the block, otherwise a code for the error that occurred Request ID := The same as in the request Detail := A status detail code, containing more information about request status Text In := 32 if the text field contains the block, or 0 if an error occurred Text := An array of 16-bit values, defined as follows: Offset Description 0 Total number of requests from applications
Writing Applications that Use 6100 BSC HALT READ Request and Response The HALT READ request cancels an outstanding READ request if the station is waiting for a line bid when you issue the HALT READ. If a line bid has already arrived or if this is not an initial READ, HALT READ has no effect. This request lets a station keep a READ posted whenever it has no data to send. If a bid arrives, the application accepts it and receives data from the other station.
Writing Applications that Use 6100 BSC The request buffer format is: Function := 70 Modifier := Doesn't matter Request ID := A unique value from 1 to 32767, application-determined Text Out := Doesn't matter Text In := Doesn't matter Text := None The response buffer format is: Function := 70 Status := 160 if BSC was processing a STOP request, otherwise 0 (whether or not a READ was cancelled) Request ID := The same as in the HALT READ request Detail := A status detail code, e.g.
Writing Applications that Use 6100 BSC READ Request and Response The READ request has several major functions, depending on the value in the modifier field and on the line state: • If the state is DISCONNECTED, the READ request implicitly connects the station. The same request can accept and acknowledge a line bid and read the first message or block. • If the state is CIRCUIT ASSURANCE, the READ request reads the ID of the calling station.
Writing Applications that Use 6100 BSC The response buffer format is: Response := 65 Status := 0 if the request was successful, otherwise a code for the error that occurred Request ID := The same as in the request Detail := A code containing more status information, for example, if a control character arrived instead of a message or block Text In := 0 If no text arrived, otherwise the number of bytes of the message or block Text := The received message or block NOTE If a READ request completes w
Writing Applications that Use 6100 BSC SET CONFIGURATION Request and Response The SET CONFIGURATION request builds or replaces the configuration block in the LIU, or establishes a user-defined ASCII<->EBCDIC translate table. This request is permitted only when the line is in DISCONNECTED state. As mentioned in "Setting Line Parameters," earlier in this section, most applications never change the values in the configuration block.
Writing Applications that Use 6100 BSC The response buffer format is: Response := 1 Status := 0 if the request was successful, otherwise a code for the error that occurred Request ID := The same as in the request Detail := A code containing more information about request status Text In := 0 Text := None CONFIGURATION BLOCK FORMAT. The format for the configuration block is as follows. For more information about the parameters, see "Line Configuration Options" in Section 1.
Writing Applications that Use 6100 BSC BSCPTPT and BSCNONSTOPON 10 2 0 = normal BSC with BSCNONSTOPOFF 1 = multileaving with BSCNONSTOPOFF %200 = normal BSC with BSCNONSTOPON %201 = multileaving with BSCNONSTOPON BSCLRC8 11 2 0 = CRC16 1 = LRC/VRC BSCASCII 12 1 0 = ASCII 1 = EBCDIC 2 = user-defined EBCDIC BSCSYNCS 13 1 Number of leading SYNs, including pad BSCREADTO 14 2 Value in .
Writing Applications that Use 6100 BSC TRANSLATE TABLE FORMAT. A translate table consists of 512 text entries: an ASCII to EBCDIC table 256 bytes long, followed by an EBCDIC to ASCII table 256 bytes long. The ASCII to EBCDIC table is really a list of EBCDIC values: the first is the value to which to translate an ASCII 0H, the second is the value to which to translate an ASCII 1H, and so on.
Writing Applications that Use 6100 BSC SETMODE Request and Response The SETMODE request is used to change the retry count for the line or the block length for transparent text. (The corresponding SYSGEN parameters are BSCRETRIES and BSCITBSIZE.) A reason to use this request might be that the station is called by several stations with different buffer sizes, or that changes in line quality demand more leniency of the protocol. By raising the retry count, you might reduce the number of failed requests.
Writing Applications that Use 6100 BSC The response buffer format is: Response := 68 Status := 0 if the request was successful, otherwise a code for the error that occurred Request ID := The same as in the request Detail := A code, containing more information about request status Text In := 0 if the request failed, otherwise 2 Text := The old retry count or block length, or nothing if the request failed To get the old values without setting new ones, use the FETCH CONFIGURATION request.
Writing Applications that Use 6100 BSC START/STOP OPERATION Request An application should never issue a START or STOP line request. START doesn't really do anything; it exists simply for compatibility with other protocol modules. If an application issues a START, the request completes immediately.
Writing Applications that Use 6100 BSC The format for the STOP request is: Function := 7 Modifier := Doesn't matter Request ID := A unique value from 1 to 32767, application-dependent Text Out := Doesn't matter Text In := Doesn't matter Text := None The response format is: Response := 7 Status := 0 if the request was successful, otherwise a code for the error that occurred Request ID := The same as in the request Detail := A code, containing more information about the request status Text
Writing Applications that Use 6100 BSC START/STOP TRACE Request and Response These requests and responses are used by CMI to trace and report line traffic and protocol events. Your application should not use the following request and response codes: 3 4 8 which starts a trace which stops a trace which delivers a trace block to CMI The CMI TRACE facility offers all the capability of these requests, as well as a readable report format. For information about the facility consult the CMI/CMP Operator's Guide.
Writing Applications that Use 6100 BSC WRITE Request and Response The WRITE request has several major functions, depending on the line state: • If the state is DISCONNECTED, the WRITE request implicitly connects the station. The same request can make a line bid and send the first message or block. • If the state is CONTROL, the WRITE request makes a line bid and sends the first message or block. • If the state is WRITE, the WRITE request sends the next message or block.
Writing Applications that Use 6100 BSC The response buffer format is: Response := 64 Status := 0 if the request was successful, otherwise a code for the error that occurred Request ID := The same as in the request Detail := A code containing more status information Text In := 0 Text := None NOTE If a WRITE request completes with a retry error (status code 162, 172, 173, or 175), the line remains in WRITE state. Therefore you may repeat the request, but that action is normally pointless.
Writing Applications that Use 6100 BSC WRITEREAD Request and Response The WRITEREAD request has several major functions, depending on the line state: • If the state is DISCONNECTED, the implicitly connects the station. accomplish ID exchange, or it can send the first block, and receive conversational reply.
Writing Applications that Use 6100 BSC The request buffer format is: Function := 66 Modifier := Doesn't matter Request ID := A unique value from 1 to 32767, applicationdependent Text Out := The length, in bytes, of the message or block (no greater than 4096) Text In := The maximum length, in bytes, of the expected reply (no greater than 4096) Text := The message or block to be sent (see Section 1 for formats). Do not include the ENQ to make a line bid; BSC sends it automatically.
Writing Applications that Use 6100 BSC NOTE If a WRITEREAD request completes with a retry error (status code 162, 172, 173, 175, or 177), the line may be in WRITE or CONTROL state, depending on when the error occurred. Do not repeat the WRITEREAD request; rather send an EOT and issue a bid or prepare to receive one. If the line bid fails, there is probably an equipment malfunction. The retry count has an impact on the number of retry errors.
Writing Applications that Use 6100 BSC STATUS CODES AND DETAILS Two fields of the response buffer contain status information. The status field contains a general message, while the detail field contains further explanation of the status code. For example, if the status code is 22 (invalid parameter), the detail code might be 128 (invalid function field). Thus the application can check the code in the status field and then, if necessary, check the detail field for more information.
Writing Applications that Use 6100 BSC Value (Decimal) Description 161 An error occurred within the 6100 subsystem. Note the contents of the detail field. If you can reproduce the error while running a trace (with all "CLIP" options), submit the output from the trace to your Tandem representative. 162 The request timed out, or a READ was cancelled by a HALT READ request. The detail field provides more information.
Writing Applications that Use 6100 BSC Value (Decimal) Description 168 A NAK arrived in response to a line bid. The other station isn't ready to accept a bid. Try again later. If the error persists, disconnect the line. This error sometimes indicates a line quality problem. 169 A WACK arrived in response to a line bid. The other station is temporarily not ready to accept a bid. Try again later. If the error persists, disconnect the line.
Writing Applications that Use 6100 BSC Value (Decimal) Description 175 The acknowledgement didn't fit the request. For example, an ACK 0 arrived instead of an ACK 1. Retries were unsuccessful. The line is in WRITE state. Send an EOT and either issue a bid or prepare to receive one. 177 The received message or block was larger than the Text In value would allow. Truncated text is delivered to the application, but may contain errors. The line is in CONTROL state.
Writing Applications that Use 6100 BSC Detail Codes If the status field contains a 22 (invalid parameter), the detail field tells you which parameter was at fault. For more information about line parameters, see the discussion of configuration options in Section 1, and the discussion of SET CONFIGURATION in Section 3. For information about parameters for a given request, see the description of that request in this section. The list below defines the detail codes in the context of status code 22.
Writing Applications that Use 6100 BSC Value (Hex) Description 9 The value specified for ID exchange (BSCIDEXCH) is out of bounds--the only legal values are 0 and 1--or you specified ID exchange for a nonswitched line. A The value specified for protocol (BSCPTPT) is out of bounds. The only legal values are 0, 1, %200, and %201. B The value specified for initial SYN characters (BSCSYNCS) is out of bounds. The legal values are 3 through 255. C This code isn't used.
Writing Applications that Use 6100 BSC Value (Hex) Description 88 The Text In value in a READ or WRITEREAD request exceeds 4096. 89 The Text Out value in a WRITE or WRITEREAD request is 0. It shouldn't be. 8A The Text In value in a READ or WRITEREAD request is 0. It shouldn't be. 8B The Text In value in a WRITE request is not equal to 0. It should be. If the status field contains a 190 (subsystem software error), the detail field provides more information about the error.
Writing Applications that Use 6100 BSC If the status code is something other than 22 or 190, the values in the detail field have the following definitions: Value (Hex) Description 0 The request was successful, or the status code requires no further explanation. 1 Line configuration has not taken place, or a SET CONFIGURATION request failed. Make a SET CONFIGURATION request before trying to connect the line. 2 No translate table has been defined.
Writing Applications that Use 6100 BSC Value (Hex) Description 15 You attempted to make a second consecutive conversational reply. In conversational mode, each station is allowed one text reply, after which the first station to make a text reply must send an acknowledgement. This restriction and status detail code do not apply to multileaving state. 16 The remote station answered a line bid with ENQ. (See the description of status code 166.
APPENDIX A FILE SYSTEM ERROR CODES This appendix lists the file system errors that have special meanings for CP6100 or the 6100 subsystem. For each error, it gives the error number, a brief description of the error and what caused it, and a corrective action you can take. For descriptions of other file system errors, consult the NonStop System Messages Manual. Errors listed under the heading "These are serious. Don't retry" indicate that something was wrong with the request or the device.
File System Error Codes The theoretical strategy for recovery is simple: backtrack to the most recent point where you knew what was going on. Here are some scenarios to illustrate the strategy: Case 1: You were transmitting data when the error occurred. The normal way to handle this case is to repeat the last transmission, somehow signalling the other station to discard any duplicate data.
File System Error Codes In the following protocols, recovery from a path switch is somewhat simplified: • In ADCCP a path switch doesn't change the state of the line. You can retry your request without loss or duplication of data. • In BSC or MPSB you can set the parameter xxxNONSTOPON, where xxx is the acronym that represents the protocol; then a path switch won't change the state of the line, and you can retry requests without loss or duplication of data.
File System Error Codes If an LIU doesn't respond to a request, CP6100 tries up to three times to establish contact through the CSM. In the meantime, requests complete with error 124. If the LIU fails to respond after three attempts at recovery, CP6100 declares the line down and completes new requests with error 66. (Then an operator must use CMI to download the line and return it to service.) If on the other hand the LIU recovers, applications can resume their use of the line.
File System Error Codes ---------------------------------------------------------------THESE ARE SERIOUS. DON'T RETRY. ---------------------------------------------------------------2 Invalid operation requested. You probably issued a call CP6100 doesn't support. Remember to use WRITEREADs for all requests to the line. ---------------------------------------------------------------12 Device has been opened exclusively. The device is in use by another application.
File System Error Codes ---------------------------------------------------------------22 Invalid request ID. The request ID in the WRITEREAD buffer is 0 or negative. Change it to a number between 1 and 32767. (CP6100 doesn't check for duplicate request IDs. Your application must manage its own request IDs, in coordination with other applications using the line.) ---------------------------------------------------------------53 File management interface error.
File System Error Codes ---------------------------------------------------------------100 Controller Not Operational. The controller is not present in its slot, is not addressed correctly, has not been powered up, or has not been downloaded. Prepare the controller for operation before you try the request again. ---------------------------------------------------------------124 Non-responding LIU; trying to reset.
File System Error Codes ---------------------------------------------------------------RETRY THESE, BUT FIRST READ NOTES IN TEXT ---------------------------------------------------------------31 No Buffer for #DEBUG. CP6100 couldn't get a buffer to service a request for CSSDBUG. This error is a specific case of error 33, below. ----------------------------------------------------------------33 Buffer Space Shortage. CP6100 couldn't get a buffer for the request. Try the operation again.
File System Error Codes ----------------------------------------------------------------200 Device Owned by Other CPU. * 210 Path Switch Occurred. * 211 CPU Failure. * 230 CPU Power On. * 231 Controller power on, channel reset, or loss of contact with the 6100 subsystem cabinet. See the discussion of "Total Subsystem and LIU Failures" in this Appendix. * * These messages indicate that a path switch has occurred or is occurring. See the discussion of path switches in this Appendix.
APPENDIX B BSC PROGRAMMING EXAMPLE A sample application using BSC begins on the next page. It illustrates mosts of the requests described in Section 3 of this book.
BSC Example ?PEP=20,SYMBOLS,INSPECT ?NOCODE ?CPU TNS/II !****************************************************************************** !****************************************************************************** !****************************************************************************** ! ! CCCC PPPPPP 6666 1 0000 0000 ! C C P P 6 6 11 0 0 0 0 ! C P P 6 1 0 0 0 0 ! C P P 6 1 0 0 0 0 ! C PPPPPP 6 6666 1 0 0 0 0 ! C P 6 6 1 0 0 0 0 ! C P 6 6 1 0 0 0 0 ! C C P 6 6 1 0 0 0 0 ! CCCC P 6666 111 0000 0000
BSC Example ?page ?PAGE “HIPO chart for this example” ! ! The HIPO chart of this program.
BSC Example ?page "Global declarations" INT file, comm^file, term^file, term^buff[0:39], error, reqid := 0; STRING .SP, .
BSC Example ?PAGE !*********************************************************************** ! ! the template diagram of the line task message : ! ! REQUEST : ! ! byte 0 1 2 3 4 5 6 7 8 ! +-------+-------+-------+-------+-------+-------+-------+-------+--! | | | | | | ! | Func | Modif | Request ID | Text out | Text in | text ..
BSC Example ?page "CONFIGURATION FOR CLIP" STRUCT clip^cfg^buff = cpline^text; BEGIN STRING LINE^TYPE; STRING CONNECTION^TYPE; STRING DTR^CONTROL; STRING SPARE; STRING CLOCK^SOURCE; STRING LINE^SPEED; INT CONNECT^TIMEOUT; INT DISCONNECT^TIMEOUT; STRING PROTOCOL^TYPE; STRING FRAME^CK^SEQ^TYPE; STRING LINE^CODE; STRING SYNC^COUNT; INT READ^TIMEOUT; STRING STATION^TYPE; STRING ID^EXCH^ENABLE; INT RETRY^COUNT; INT BLOCK^LENGTH; END; END; ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ^ | | CONFIGURATION BLOCK FOR BSC P
BSC Example ?page ! LITERAL cpline^buff^byte^size = $LEN (cpline^buff^template), clip^req^hdr^len = $LEN (cpline^buff^template.clip^req^hdr), clip^rsp^hdr^len = clip^req^hdr^len, ! the following are used in TEXTOUT field of the CLIP request header config^len = 22, ! length for the config bolck in bytes cpline^text^len = $LEN (cpline^buff^template.cpline^text); LITERAL MAX^COMM^READ max^term^read = = 88, 78; !LARGEST COMM READ count !largest ternimal read count INT .
BSC Example ?page "write^term" !********************************************************************* ! ! Function: Got data from line and ready to write to the terminal. ! !********************************************************************* PROC WRITE^TERM(buffer,count); INT .
BSC Example ?PAGE "COMMUNICATIONS ERROR MESSAGE PROCEDURE - CLIP^STATUS^HANDLER" !******************************************************************* ! ! This PROC is used for error handling. In this example, a two line ! message is displayed on the screen and no retry is atempted. The ! first line is the status error returned in the response from the ! clip, and the second is the status detail. ! FILE ERRORS are handled by .....
BSC Example .
BSC Example detail^message^others = 'P' := [ !0 ! " NO ADDITIONAL INFORMATION AVAILABLE !1 ! " LINE NOT CONFIGURED !2 ! " NO USER TRANSLATE TABLE !3 ! " LINE BUSY !4 ! " NO REQUEST ACTIVE !5 ! " TRACE IS ACTIVE !6 ! " CONNECT TIMEOUT !7 ! " DISCONNECT TIMEOUT !8 ! " LAST REPLY ENQ !9 ! " TIMEOUT WAITING FOR BID !10! " CONSECUTIVE RVI READS !11! " CONSECUTIVE CONVERSATIONAL REPLIES !12! " ENQ RESPONSE TO BID !13! " ENQ ENQ RETRY ABORT ON BID !14! " RVI READ INITIAL ", ", ", ", ", ", ", ", ", ", ", ", ", ",
BSC Example END BEGIN RSCAN DETAIL^NUMBERS^ERR22[28] UNTIL detail[1] -> @SP22; IF $CARRY THEN BUFFER ':=' UNKNOWN^ERROR^MESSAGE FOR error^message^length ELSE BEGIN error^index := @SP22 - @DETAIL^NUMBERS^ERR22; BUFFER ':=' detail^message^22[error^message^length * error^index] FOR error^message^length; END; END; ! **** of detail status for error 22 ELSE IF status = 190 THEN BEGIN RSCAN DETAIL^NUMBERS^ERR190[2] UNTIL detail[1] -> @SP190; ! *********CHECK FOR ENTRY NOT ON LIST ************************ error^
BSC Example ?PAGE "COMM COMPLETION - COMM^COMPLETE" !********************************************************************* ! ! Function: upon completion of the outstanding read, data is moved ! to the term^buff and post a new read on the line to send ! an ACK and receive the EOT. (you may have another block ! to receive in your program). ! It then writes the received data to the terminal and posts ! a new read on the line (an AWAITIO is owed to this ! last WRITEREAD).
BSC Example ?page "WRITE TO COMM-LINE PROCEDURE - WRITE^COMM" !********************************************************************* ! ! Function: Write a message to the line, EOT the line and post ! a new read on the line. ! ! Called by : TERM^COMPLETE ! !********************************************************************* PROC WRITE^COMM(COUNT); INT COUNT; BEGIN INT ERROR; string status = error; s^cpline^buffer ':=' clip^write^req for 2; reqid := (reqid '+' 1); !WRITE THE DATA cpline^buffer.clip^req^hdr.
BSC Example !DO A CONNECT !REQUEST FOR !A SWITCHED !LINE HERE END; END; s^cpline^buffer.clip^req^hdr.func ':=' clip^read^req for 2; reqid := (reqid '+' 1); cpline^buffer.clip^req^hdr.reqid := reqid; cpline^buffer.clip^req^hdr.txtout^len := 0; cpline^buffer.clip^req^hdr.
BSC Example ?PAGE "TERMINAL COMPLETION PROCEDURE - TERM^COMPLETE" !********************************************************************* ! ! Function: This routine will write a message, entered on the terminal, ! to the line. STX & ETX must be added to the buffer. ! First, abort the outstanding read. If read aborted ! sucessfully, the write operation follows. otherwise, ! "TRANSMISSION ABORTED" is displayed on the screen.
BSC Example FOR TERM^READ^COUNT & ETX -> @SP; CALL WRITE^COMM(@SP - @s^cpline^text^buffer); END !WE CAN SEND !THE MESSAGE ELSE BEGIN ! error <> operation^timed^out (162) CALL clip^status^handler(term^buff); s^cpline^buffer.clip^req^hdr.func ':=' clip^read^req for 2; reqid := (reqid '+' 1); cpline^buffer.clip^req^hdr.reqid := reqid ; cpline^buffer.clip^req^hdr.txtout^len := 0; cpline^buffer.clip^req^hdr.
BSC Example ?PAGE"INITIALIZATION" !********************************************************************* ! ! Function: open the terminal and the line. After the open to the line, ! a set^configuration message to the CLIP (this is optional, ! as open will set SYSGENed configuration message to CLIP if ! the AUTOCONF modifier was used). ! The next thing it does is send connect^request which ! raises DTR. Then it posts the first read on the line. ! An AWAITIO is owed to this request.
BSC Example cpline^buffer.clip^req^hdr.txtin^len := 0; cpline^buffer.cpline^text ':=' clip^config FOR config^len; cpline^write^count := config^len '+' clip^req^hdr^len; CALL WRITEREAD (comm^file, cpline^buffer,cpline^write^count, clip^rsp^hdr^len,cpline^cnt^recvd); CALL AWAITIO (comm^file,,count); IF < THEN BEGIN CALL FILEINFO (comm^file,error); CALL DEBUG; ! ******* process file level error END ELSE BEGIN ! process status level error error := 0; status [1] := cpline^buffer.clip^rsp^hdr.
BSC Example END; END; B-20 ! ***** of process level error !INITIALIZE
BSC Example ?page "Check Term Error - CHECK^TERM^ERROR" !******************************************************************* ! ! Function: Check if the BREAK key or CONTROL^Y (END^OF^FILE) is ! received from the terminal. Stop this process when ! required or re-promt the terminal with "?".
BSC Example ?page "MAIN PROCEDURE - CP6100^EXAMPLE" !******************************************************************* ! ! MAIN : This procedure initializes the CP6100 BSC point to point ! line and the user terminal. ! One outstanding AWAITIO for the completion by either ! device. Data entered thru the terminal will be sent ! to the remote terminal via the 6100 BSC line. ! Data received from the remote terminal will be displayed ! on the user terminal.
BSC Example cpline^buffer.clip^req^hdr.reqid := reqid; cpline^buffer.clip^req^hdr.txtout^len := 0; cpline^buffer.clip^req^hdr.
APPENDIX C ASCII/EBCDIC CODE TRANSLATION TABLE The table below lists the standard values used for translation from ASCII to EBCDIC and vice versa. There are application requests you can use to override these values. Table C-1.
ASCII/EBCDIC Codes Table C-1.
ASCII/EBCDIC Codes Table C-1.
ASCII/EBCDIC Codes Table C-1.
ASCII/EBCDIC Codes Table C-1.
ASCII/EBCDIC Codes Table C-1.
ASCII/EBCDIC Codes Table C-1.
INDEX ABORT request 3-22, 3-27, 3-59, 3-66 Access Exclusive 3-2, A-5 Read/write 3-2 Shared A-5 Acknowledgements ACK 0/ACK 1 1-20, 1-22 Alternating positive 1-24 ASCII/EBCDIC code translation table C-1 AUTOCLOSE parameter 3-19, 3-21, A-3, A-6 AUTOCONF parameter 3-4, A-3 AUTOLOAD parameter 3-21, A-4 Basic message format 1-8 Bidding for the line 1-22, 2-11, 3-8, 3-35 Contention and resolution 3-10 Block check sequence (BCC) 1-4, 1-9, 1-10, 1-14, 1-16 BSCLRC8 1-45 BSC Concepts and context 1-5 Features of 1-2 In
Index BSCITBSIZE Line parameter BSCLRC8 Line parameter BSCNONSTOPON Line parameter BSCPPSW, BSCPPNSW Line parameter BSCPTPT Line parameter BSCREADTO Line parameter BSCRETRIES Line parameter BSCSECONDARY Line parameter BSCSYNCs Line parameter BSCSYNCS Line parameter 1-44, 3-49, 3-64 1-45 1-46, 3-21, 3-28, A-3 1-44, 3-63 1-44, 3-64 1-46, 3-64 1-46, 3-49, 3-64 1-44, 3-63 1-45 3-64 Call versus request 1-2 CANCEL call 3-22 Cancelling a request 3-22 Circuit assurance procedures 1-19, 3-6 CIRCUIT ASSURANCE state
Index Data Carrier Detect (DCD) 2-28 Data link control procedures 1-19 Data link escape (DLE) 1-16 Data rate How to set 1-42 Maximum for BSC 1-4 Data Set Ready (DSR) 2-4, 2-25, 3-31 Data Terminal Ready (DTR) 2-4, 2-25, 3-31 Data transfer 1-24, 3-13 Variations 1-27 Detail codes Definitions 3-63 Disconnect 1-21, 1-27, 3-60 Timeout 1-43, 3-63 DISCONNECTED state 2-4 Applicable requests and functions 2-7 Status codes that imply transitions 2-5 Disconnecting the line 1-27 Duplex 1-8 Options in BSC 1-4, 1-43 End I
Index HALT READ request 3-22, 3-41, 3-60 HALTPOLL call (ENVOY) 3-27 I/O pool space Use by CP6100 A-8 ID exchange 1-4, 1-19, 1-44, 2-8, 3-6 ITB 1-14 Leading graphics 1-4 Leading pad 1-9 Limited conversational mode 1-38 Line configuration options 1-41 Line interface unit (LIU) A-6, A-7 Supplying transmit clock 1-42 Line states and transitions 2-2 Line turnaround 1-26 Overlapping with processing 2-27 Link Defined 1-5 Link and station management 2-1 Memory management CP6100 considerations A-8 Message blocking 1
Index Parameters Character code 1-45 Error handling 1-46 Line and modem control 1-42 Message format 1-44 Transmission control 1-44 Path switches 1-46, 3-21, 3-28, A-1, A-9 Point-to-point links 1-5, 1-7 Power failures A-4, A-7 Primary and secondary stations 1-6 Queuing (See request queuing) READ request 1-24, 1-34, 3-12, 3-17, 3-41, 3-43 READ state 2-16 Applicable requests and functions 2-18 Status codes that imply transitions 2-17 Read timeout 1-46 Receive Clock (RxC) 2-29 Recovering from errors 3-20 Relinq
Index Statistics block format 3-40 Status codes Definitions 3-59 Status detail codes Definitions 3-63 Status Detail field In WRITEREAD buffer 3-25, 3-59 Status field In WRITEREAD buffer 3-25, 3-59 Status probe By CP6100 A-4, A-7 STOP 3-51 CMI A-6 Issued by CP6100 3-19, 3-51 STOP request 3-21 STOP TRACE 3-53 SUSPEND CMI A-6 Switched lines 1-4, 1-43 BSCPPSW, BSCPPNSW 1-44 SYN pattern How to define 1-45 Idle 1-39 Initial 1-9 Within a message 1-15 Temporary text delay (TTD) 1-27, 1-40 Terminal-Supplied Transmit
Index WRITE state 2-19 Applicable requests and functions 2-21 Status codes that imply transitions 2-20 WRITEREAD buffer 3-23/25 WRITEREAD call 1-2, A-5 Read and write counts 3-23 WRITEREAD request 1-24, 1-36, 3-15, 3-56 Writing applications that use BSC 3-1 Index-7
