Networking and Data Communications Library CP6100 I/O Process Programming Manual Abstract This manual describes the CP6100 I/O process. It provides information for application programmers and system managers. Part Number 109465 Edition Second Published Product Version Release ID Supported Releases September 1994 CP6100 B20 D20.03 This manual supports B00 and all subsequent releases until otherwise indicated in a new edition.
Document History Edition Part Number Product Version Earliest Supported Release Published First Update 1 Second 82410 82225 109465 CP6100 B00 CP6100 B20 CP6100 B20 B00 B00 B00 March 1985 October 1985 September 1994 New editions incorporate any updates issued since the previous edition. A plus sign (+) after a release ID indicates that this manual describes function added to the base release, either by an interim product modification (IPM) or by a new product version on a .
NEW AND CHANGED INFORMATION This represents the second update to the first edition of the CP6100 I/O Process Programming Manual. The information provided applies only to NonStop systems. This update incorporates the following changes to the manual: • Changes the description of error 124 in Appendix A.
(This page left intentionally blank)
CONTENTS PREFACE.................................................. vii SECTION 1: INTRODUCTION................................. What Is CP6100?........................................ How Do I Use It?....................................... How Is CP6100 Related to ENVOY and ENVOYACP?........... First Generation: Communication Controllers.......... Second Generation: Programmable Communication Subsystem.......................................... Implications for CP6100..............................
Contents Balancing the Communication Workload................. 3-24 Revising Line Parameters to Improve Performance...... 3-32 Problem Determination.................................. 3-38 APPENDIX A: FILE SYSTEM ERROR CODES..................... A-1 APPENDIX B: CPTEST...................................... Input Line Format...................................... Numbers................................................ Operators.............................................. CPTEST RUN Command..................
PREFACE This book begins a series describing the CP6100 I/O process and related protocols. The organization and content of the book are as follows: • Section 1 discusses the purpose of CP6100 and points out advantages over ENVOY and ENVOYACP. • Section 2 is an overview of CP6100 application programming, without details or considerations for specific protocols. • Section 3 is an overview of CP6100 system management.
Preface The CP6100 process is a low-level interface. The application implements a part of the protocol and must therefore be closely coupled with the protocol module. For this reason, you'll find the books in this series more detailed than most, with information about protocol internals, as well as user interfaces.
SECTION 1 INTRODUCTION One of the most common traits of computer networks is diversity. Especially in a large organization, the work of applications is likely to be spread among computers, terminals, and communication equipment of various manufacture. Not only are there different kinds of equipment, but also different kinds of communication lines, with varying configuration requirements.
Introduction WHAT IS CP6100? CP6100 is a general-purpose I/O process pair. It provides the file system interface for application processes in a Tandem host to communicate with protocol modules in a Tandem 6100 Communication Subsystem. Each protocol module controls one line, as illustrated in Figure 1-1. Tandem currently offers the following protocol modules as products: • 6100 BSC. This protocol lets the Tandem system act as the primary or secondary station on a binary synchronous point-to-point line.
Introduction 1 Application Process CPU 1 CPU 2 CP6100 I/O Proc CP6100 I/O Proc 2 6100 Subsystem 6101 3 Comm Line Protocol Protocol • • • Protocol Comm Line Comm Line $comm 6101 6100 subsystem hardware consists of two 6101 controllers and up to 15 line interface units running protocols. Legend 1 The application process makes a file system request to $comm. 2 CP6100 accepts the request and sends it to the line. Notice that CP6100 is a NonStop process pair.
Introduction HOW DO I USE IT? To build an interface to a specific device (or to simulate a device), you follow one of the design strategies shown in Figure 1-2: First option. Write a process that uses file system calls--like OPEN, SETMODE, and WRITEREAD--to communicate with CP6100 and "fill in" those elements of protocol your application requires. Clearly, you don't have to repeat functions already in the protocol module.
Introduction The manuals in this series describe the features covered by the protocol modules, so you can determine what functions your application program must perform.
Introduction HOW IS CP6100 RELATED TO ENVOY AND ENVOYACP? Before the introduction of the Tandem 6100 communication subsystem, two Tandem software products had functions similar to those of CP6100. ENVOY provided a file management interface to a range of byte-oriented protocols, and ENVOYACP did the same for a range of bit-oriented protocols. CP6100 improves on the two earlier products by taking advantage of the features of the 6100 subsystem.
Introduction functions supplied by the controllers were implemented in microcode; each controller has its own set. Controllers would also manage the electrical interfaces for lines; for example, the asynchronous controller supported the RS-232 standard, as well as current loop connection and an autodialer interface.
Introduction Second Generation: Programmable Communication Subsystem (6100) The 6100 subsystem is designed to provide the same function as its predecessors while offering greater fault-tolerance and flexibility. Well-planned configurations can also show substantial improvements in throughput over configurations based on the older hardware. The next few paragraphs describe the features that account for these improvements.
Introduction Processor A Processor B I/O Process Primary I/O Process Backup I/O Channel A I/O Channel B 6101 Controller A Port A Port B Path to $LINE1 Path to $LINE1 Interface to $LINE1 Path to $LINE1 Port A Interface to $LINE2 • • • 6101 Controller B Interface to $LINE Port B Path to $LINE1 S5064-004 Figure 1-4a.
Introduction Processor A Processor B I/O Process Primary I/O Process Backup I/O Channel A I/O Channel B 6101 Controller A Port A Path to $LINE1 Interface to $LINE1 Interface to $LINE2 • • • Interface to $LINE Path to $LINE1 6101 Controller B Port B S5097-001 Figure 1-4b.
Introduction between controllers. In a single-port controller configuration, each controller must be associated with a different processor. The exact division of work depends on the traffic you expect on the lines, and on the overhead for controlling each line; simply assigning half the lines to one controller and half the lines to the other might not provide the best possible balance.
Introduction Implications for CP6100 In summary, when you develop an interface with CP6100 or convert an existing interface to use CP6100, applications that use the interface gain several important benefits: | • | | Availability. Because there are up to four paths to any line controlled by CP6100, not even a controller failure can make a line unavailable.
SECTION 2 USING CP6100: PROGRAMMING This section is for programmers who plan to use CP6100. describes: It • the interface between your application and a communication line • the services CP6100 provides to your application • background information useful for handling errors and exceptions Other books describe the available protocol modules. See the preface for a list of those books. (Some protocols may be added after the publication of this manual.
Using CP6100: Programming • The CP6100 I/O process. This process provides the file system interface for one or more application processes to communicate with up to 15 lines attached to the same 6100 subsystem. (One subsystem can have more than one pair of CP6100 processes. You assign processes to specific lines with the SYSGEN program.) • A protocol task. A protocol task runs in an LIU on the 6100 subsystem, and controls the line attached to that LIU.
Using CP6100: Programming 3 Interprocess EIO 2 Communication Instruction An Application CP6100 that You Write I/O Process 5 4 1 6100 Subsystem Line Interface Unit Protocol Task (Protocol Action) (Acknowledgement) Legend 1 Application makes GUARDIAN file system request, e.g., WRITEREAD. 2 CP6100 accepts the request and routes it to the protocol task. 3 Protocol task controls line, according to request. 4 Protocol task replies to CP6100. 5 CP6100 completes the application request.
Using CP6100: Programming Some activities of CP6100 are largely transparent to your program and independent of requests your program makes. These activities nonetheless contribute to the success of your application. For example: • CP6100 runs as a NonStop process pair. If a failure occurs in the primary processor or its I/O channel, control is switched to the backup process, which uses the backup processor and I/O channel.
Using CP6100: Programming • OPEN gives the application access to the line. A line can be dedicated to one application or shared with others, or the same application can open the line more than once. • CLOSE stops the connection between an application and the line. (Other applications can still use the line.) • SETMODE lets requests from the application to the line be completed in any order. • CANCEL cancels the oldest request pending for the line.
Using CP6100: Programming • READ delivers unsolicited messages from the protocol task to the application. For example, in the case of a serious line quality problem, an application might want to know, even if no request is pending. To be sure to receive such information, an application keeps a READ call outstanding. SOME PROTOCOLS DO NOT SUPPORT THIS FEATURE.
Using CP6100: Programming An application normally issues requests in the following order for each line it uses: 1. OPEN to gain access to the line, to determine whether access is exclusive or shared, to specify nowait access and the number of concurrent requests allowed. (Remember to count the READ if you're using a protocol that supports it.) If a process will open the line more than once without first closing it, it must ask for shared access. 2. SETMODE for requests to complete in any order.
Using CP6100: Programming | | | | | | | | COMPONENT FAILURES IN THE NonStop SYSTEM. The 6100 subsystem provides two paths to any line for the single-port controller configuration and four paths to any line for the dual-port controller configuration. Thus, your programs maintain their access to a line even if a processor, I/O channel, controller port, or controller fails.
Using CP6100: Programming Processor A Processor B I/O Process Primary I/O Process Primary I/O Channel A I/O Channel B Port A Port B 6101 Controller A Interface to $LINE1 Port A Interface to $LINE2 Interface to $LINE3 • • • 6101 Controller B Interface to $LINE Port B S5064-007 Figure 2-3a.
Using CP6100: Programming Processor A Processor B I/O Process Primary I/O Process Primary I/O Channel A I/O Channel B Port A 6101 Controller A Interface to $LINE1 Interface to $LINE2 Interface to $LINE3 6101 Controller B • • • Interface to $LINEn Port B S5097-002 Figure 2-3b.
Using CP6100: Programming If no path exists between the controllers and the 6100 subsystem cabinet--for instance, if both cables are unplugged or the subsystem cabinet has lost power--CP6100 queues user requests and completes them every 30 seconds with file system error 231. When power returns, applications can continue using the line. (If the SYSGEN AUTOCLOSE parameter is set, applications must close and reopen the line before they can use it.
Using CP6100: Programming DATA COMMUNICATION ERRORS. A variety of communication problems have the same symptom: a request from the Tandem system does not bring an acknowledgment, or the reply received is unreasonable given the communication protocol.
Using CP6100: Programming • Errors Unrelated to Specific Requests. You find out about this kind of error when a READ call completes. The application finds the error message in the READ buffer. Errors reported in the READ buffer are normally line or modem problems perceived by the protocol task: for example, the number of line errors exceeds a threshold prescribed for the line. Some protocols, like BSC, do not support this feature.
Using CP6100: Programming example BSC, provide two levels of status in the buffer: the status field gives a general description of the error that occurred, and the detail field gives more information pertaining to the error. For specific descriptions of the status codes returned by each protocol, consult the books that describe the protocols. Notice that when a WRITEREAD call completes with a condition code of zero, that doesn't mean the application request completed without error.
Using CP6100: Programming ----------------------------------------------------------------| | | THESE ARE SERIOUS. DON'T RETRY. | | ------------------------------------------------------------ | | 2 Invalid operation requested. | | ------------------------------------------------------------ | | 12 Device in use, opened exclusively. | | ------------------------------------------------------------ | | 14 Device does not exist.
(This page left intentionally blank)
SECTION 3 USING CP6100: MANAGING LINES The success of an application depends not only on good programming, but also on careful management of each system and its resources. Decisions the system manager makes can affect dramatically the cost, performance, and reliability of applications. This section is for system managers who will manage CP6100 lines.
Using CP6100: Managing Lines SOFTWARE INSTALLATION AND LINE CONFIGURATION Before any application can use a CP6100 line, you have to install the system software and describe the line to the system. This procedure entails the following steps, taken in sequence: 1. Prepare a SYSGEN configuration file to describe the 6100 subsystems, the supporting software (like CSM), and the CP6100 lines. 2.
Using CP6100: Managing Lines • Define the paths in the PATHS paragraph. Each entry represents a pair of controllers and identifies two paths, one through each controller, to the lines in the subsystem. A line attached to the subsystem can have either path as its primary; its primary CPU will be the one assigned to the appropriate controller in the CONTROLLERS paragraph.
Using CP6100: Managing Lines ----------------------------------------------------------------| | | CONTROLLERS: | | | | !Name Product # CPUs Subchannels Modifiers | | CIU1 6101 4,5 %40 ; | | CIU2 6101 5,4 %100 ; | | | | PATHS: | | | | !Path Controller Modifiers | | !Name Names | | COMMA CIU1-CIU2 ALTERNATE_PATH COMMB; | | | | | | MICROCODE_FILES: | | | | C9304P00 $SS10.CSSCIU.C9304P00; !for CIU | | C9310P00 $SS10.CSS10.C9310P00; !for BSC | | C9312P00 $SS10.CSS10.
Using CP6100: Managing Lines SINGLE-PORT CONTROLLERS. A communication subsystem having single-port controllers is configured as if only one controller existed for the subsystem. To add a communication subsystem having single-port controllers to a NonStop System and define the CP6100 lines attached to the subsystem, you make the following additions to the configuration file: • Define the 6101 controllers in the CONTROLLERS paragraph.
Using CP6100: Managing Lines | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ----------------------------------------------------------------| | | CONTROLLERS: | | | | !Name Product # CPUs Subchannels Modifiers | | CIU1 6101 4,5 %40 ; | | | | | | | | PATHS: | | | | !Path Controller Modifiers | | !Name Names | | COMMA CIU1 ; | | | | | | MICROCODE_FILES: | | | | C9304P00 $SS10.CSSCIU.C9304P00; !for CIU | | C9310P00 $SS10.CSS10.C9310P00; !for BSC | | C9312P00 $SS10.CSS10.
Using CP6100: Managing Lines Some Configuration Issues Planning a configuration is detailed work. For each kind of line you decide the values of many parameters, which affect the electrical interface and protocol operation. The System | Management Manual for Tandem NonStop Systems describes the | parameters for each kind of line. This section mentions a few considerations that apply to all CP6100 lines.
Using CP6100: Managing Lines and STARTDOWN configuration parameters. Some managers make a practice of defining extra lines, so that a SYSGEN won't be required every time a new line is installed. By setting the STARTBOOT and STARTDOWN parameters, you prevent the system from trying to download an LIU that isn't there. • Several parameters you define in SYSGEN affect the way CP6100 responds to component failures.
Using CP6100: Managing Lines There are two important points you should consider when configuring single-port controllers: • The single-port controller environment is configured to look to SYSGEN as if only one controller were installed--there is no alternate path. Therefore, you cannot configure various I/O processes on different paths in the configuration file. • Whenever you use CMI to alter an I/O process to use the other path, a CPU switch always results.
Using CP6100: Managing Lines | | Guide). Thus, if the PROGID is set, the owner is the same user who owns the CMP object file, or a person that user explicitly assigns. You secure CMP instead of CMI because it is CMP that executes the line control functions. Anyone can run CMI, but only authorized users can make privileged requests. For CP6100, all commands are privileged except STATUS, INFO, and TRACE.
Using CP6100: Managing Lines You use this command to make the line accessible to applications. If the line is already in START state, this command has no effect. STOP or ABORT. These commands abruptly stop all work on the line. No new requests are accepted; pending requests are rejected with file system error 66.
Using CP6100: Managing Lines for LOAD, BOOT --> RUN for RESET, RUN --> BOOT The CONTROL command is legal only if the line is in the STOP state. That state may result from an earlier STOP command, from an error that caused CP6100 to stop the line, or from a cold-load of the system if the STARTDOWN parameter was specified in SYSGEN. EXAMINING AND CHANGING THE CONFIGURATION CMI provides facilities for changing the configuration of a line.
Using CP6100: Managing Lines The typical command context for ALTER LINE , PROGRAM is: 1. Use STOP to stop the line. 2. Use ALTER LINE , PROGRAM to change the program to be downloaded. 3. Use START to start the line again. The ALTER LINE , PROGRAM command requires that the line be stopped. Remember that a change in the protocol affects all users of the line. Changing the protocol to benefit one application can make it impossible for other applications to use the line.
Using CP6100: Managing Lines | | as given in the Communications Management Interface (CMI) Operator's Guide. • For any parameter you do not specify in the ALTER LINE , CONFIG command, the value specified in SYSGEN or in a previous ALTER command will appear in the template block. • Changes you make with ALTER LINE , CONFIG last until the next cold-load or the next ALTER LINE , CONFIG command. • A change in the configuration of a line affects all users of the line.
Using CP6100: Managing Lines SYSGEN Configuration File If you specified AUTOCONF, CP6100 keeps a template of the configuration block. Upon cold load, this block contains the values specified to SYSGEN. Configuration Parameters for $LINE4 CP6100 I/O Process Template for $LINE4 Configuration Block The ALTER LINE , CONFIG command changes information in the template block.
Using CP6100: Managing Lines ALTER LINE , OPCLASS This command determines the range of protocols an LIU will accept. Given the current product offering, the reasonable values are BISYNC (if you're going to use the BSC, TINET, or MPSB protocol), BITSYNC (if you're going to use the ADCCP protocol), or ANY (if you plan to use both kinds of protocol on the same line). The command is required if you wish to change from one type of link to another.
Using CP6100: Managing Lines INFO LINE , OPCLASS This command displays the range of protocols the line will accept. The possible values are BISYNC, BITSYNC, or ANY. If the line has not been downloaded since the last ALTER LINE , OPCLASS command, the OPCLASS value might be inconsistent with the running protocol. For example, if an LIU were running BISYNC and you changed the OPCLASS to BITSYNC, the restriction would not take effect until the next download.
Using CP6100: Managing Lines LINE MONITORING AND LOAD BALANCING When you first establish a NonStop System or EXPAND network configuration, you take into account the traffic patterns of your network and its applications, as well as the quality you expect of the communication lines. As the network and its applications grow and change, and as communication carriers change their offerings and standards, you may find you have to tune your configuration for performance, reliability, and cost-effectiveness.
Using CP6100: Managing Lines To monitor a line for quality problems--really, to monitor the whole link between the NonStop System and the remote station-you use the CMI STATUS LINE command.
Using CP6100: Managing Lines Monitoring Line Performance To evaluate the performance of a line, you consider three major factors: • The throughput of the line: the amount of data an application can transfer in a given time. (Because control characters and other protocols are transparent and uninteresting to business applications, they are best excluded from this figure.
Using CP6100: Managing Lines has overhead for new messages and message blocking; this overhead includes processing time in the LIU and extra bytes or bits in the data stream. The effects of changing specific parameters are described later in this section. • Line quality. Poor line quality results in frequent retries of operations. Thus processing increases without a corresponding increase in throughput. • Protocol overhead and line delays. There is normally little you can do about protocol overhead.
Using CP6100: Managing Lines HOW TO MEASURE PERFORMANCE. To measure the performance of lines and create an efficient configuration, you use three Tandem products: 1. Use XRAY to measure the lines, I/O processes, and applications. 2. Use CMI to make provisional configuration changes. 3. Repeat steps 1 and 2 until you are pleased with the results. 4. Modify the SYSGEN configuration file and run INSTALL. For details about these products, consult the manuals that describe them. WHEN TO MEASURE.
Using CP6100: Managing Lines To examine the results of your experiment, use XRAYSCAN with the following entity selection commands: • LINE, to report the throughput and other information for lines. When XRAY reports the number of bytes transferred on a CP6100 line, it is actually counting frames transferred between LIUs and 6101 controllers. • PROCESS, to report the CPU usage of I/O and application processes.
Using CP6100: Managing Lines Balancing the Communication Workload One way to balance the communication workload is to change the distribution of work between the CPUs or controllers in a 6100 subsystem. CMI has commands that accomplish this end by causing different kinds of path switches. | | | | | | | | | | | | | SINGLE-PORT CONTROLLERS. The single-port controllers environment appears to SYSGEN as if only one controller were installed and, therefore, has no alternate path.
Using CP6100: Managing Lines To switch control of a set of lines to the other controller, without switching control to the other CPU, you give either one or two commands in sequence, depending on the configuration: • If both controllers in the subsystem are currently owned by the same CPU, give the ALTER PROCESS command with the PATH option. That command switches not only the line you name, but also all other lines controlled by the same I/O process.
Using CP6100: Managing Lines 1 2 1 2 ALTER CIU $CSM.#A, A A CPU $LINE2 $LINE2 $LINE1 $LINE1 B B The path to $LINE1 and $LINE2 is through CPU 1 and Controller A. The path to $LINE1 and $LINE2 is through CPU 2 and Controller A. S5064-009 Figure 3-4.
Using CP6100: Managing Lines 1 2 1 2 $LINE3 $LINE3 $LINE1, $LINE2 $LINE1, $LINE2 A ALTER PROCESS $LINE1, A PATH $LINE3 $LINE2 $LINE3 $LINE2 $LINE1 $LINE1 B B The path to $LINE1, $LINE2, and $LINE3 is through CPU 1 and Controller A. $LINE1 and $LINE2 are controlled by the same I/O process. $LINE1 and $LINE2 switch to Controller B. $LINE3 does not switch, because it is controlled by a different I/O process. S5064-010 Figure 3-5a. Controller Switch.
Using CP6100: Managing Lines 1 2 1 2 $LINE3 $LINE1, $LINE2 $LINE3 $LINE1, $LINE2 ALTER CIU $CSM.#B, A A CPU $LINE3 $LINE2 $LINE3 $LINE2 $LINE1 $LINE1 B B The path to $LINE3 is now through CPU 1. $LINE1 and $LINE2 are unaffected: the path to them is still through CPU 1 and Controller A. The path to $LINE1 and $LINE2 is through CPU 1 and Controller A. $LINE1 and $LINE2 are controlled by the same process. The path to $LINE3 is through CPU 2 and Controller B.
Using CP6100: Managing Lines To switch control of a set of lines to the other controller and the other CPU, you give either one or two commands in sequence, depending on the configuration: • If the controllers in the subsystem are currently owned by different CPUs, give the ALTER PROCESS command with the PATH option. That command switches not only the line you name, but also all other lines controlled by the same I/O process.
Using CP6100: Managing Lines 2 1 1 2 $LINE3 $LINE1, $LINE2 $LINE3 $LINE1, $LINE2 A ALTER PROCESS $LINE1, A PATH $LINE3 $LINE2 $LINE3 $LINE2 $LINE1 $LINE1 B B The path to $LINE1, $LINE2, and $LINE3 is through CPU 1 and Controller A. $LINE1 and $LINE2 are controlled by the same I/O process. Controller B is owned by CPU2. $LINE1 and $LINE2 switch to Controller B and CPU 2. $LINE3 does not switch, because it is controlled by a different I/O process. S5064-012 Figure 3-6a.
Using CP6100: Managing Lines 1 1 2 $LINE1 $LINE3 2 $LINE1 $LINE3 $LINE2 $LINE2 ALTER CIU $CSM.#B, A A CPU $LINE3 $LINE2 $LINE2 $LINE3 $LINE1 $LINE1 B B The path to $LINE1 and $LINE2 is through CPU 1 and Controller A. The path to $LINE3 is through CPU 1 and Controller B. The path to $LINE3 switches to CPU 2. 1 2 $LINE2 $LINE3 $LINE1 ALTER PROCESS $LINE1, A $LINE1 switches controller and CPU.
Using CP6100: Managing Lines Revising Line Parameters to Improve Performance Among the parameters you define in SYSGEN--and possibly modify with CMI--there are quite a few whose values affect the | efficiency of a line. The System Management Manual for Tandem NonStop Systems describes the parameters in detail. There are also descriptions in the books that describe the protocols. The next few pages discuss parameters only in terms of their effects on performance.
Using CP6100: Managing Lines For ADCCP only: IDLETIMER. This parameter applies to the ADCCP protocol; it determines the interval between passes through the poll list for primary stations, and between idle RR frames for combined stations. This value has a minor effect on the performance of the line. L1RETRY. This parameter specifies how often an operation is tried at the link level before an error is reported to the application.
Using CP6100: Managing Lines For BSC only: BSCBAUD1200, BSCBAUD1800...BSCBAUD19200. These parameters apply only to the BSC protocol, and only in those cases where the LIU provides the transmit clock. (See the discussion of | BSCINTERNALCLK in the System Management Manual for Tandem NonStop Systems.) The baud rate setting determines the data rate of the line, which is one of the primary factors determining its throughput. BSCITBSIZE. This parameter prescribes the size of a block for the BSC protocol.
Using CP6100: Managing Lines For MPS-TINET only: | | | TITIMEOUT. This parameter specifies the interval, in 10-ms | units, that MPS-TINET waits for a station to respond to a poll or | write sequence. If the station does not respond within the time | interval specified, MPS-TINET retries the operation until a | proper response is received, or until the retry count (see | TIRETRIES) is exhausted. | | | | TIRETRIES.
Using CP6100: Managing Lines | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For MPS-B only: MPSBTIMEOUT. This parameter specifies the interval, in 10-ms units, that MPS-B waits for a station to respond to a poll or write sequence. If the station does not respond within the time interval specified, MPS-B retries the operation until a proper response is received or until the retry count (see MPSBRETRIES) is exhausted. MPSBPOLLINTERVAL.
Using CP6100: Managing Lines MPSBNOAUTODISABLE. This parameter specifies that a station in the poll list is not automatically disabled following the completion of a normal read operation. MPSBAUTODISABLE. This parameter specifies that a station in the poll list is disabled following the completion of a normal read operation. Disabling the station saves processing time because the application need not issue a Control Disable Station request to allow for host transaction processing.
Using CP6100: Managing Lines PROBLEM DETERMINATION When a 6100 subsystem or a CP6100 line behaves in an unexpected or undesirable way, there are several ways to discover the source of the problem: • Console error messages. Component failures and attempts at recovery produce these messages on the console. For descriptions of the messages, see the System Messages Manual for Tandem NonStop Systems. • DIAG6100. These diagnostics let you test controllers, LIUs, and other components online.
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 System Messages Manual for Tandem NonStop Systems. | Errors listed under the heading "These are serious.
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. ---------------------------------------------------------------160 Request Invalid for Line State.
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 ----------------------------------------------------------------124 Indicates that a line reset is in progress. An application receiving an error 124 should retry the operation. When a path switch occurs in a vertical configuration (where the twi paths to the CIU are on the same CPU), error 124 is returned and the application should retry the operation.
(This page left intentionally blank)
APPENDIX B CPTEST CPTEST provides an interactive interface to a protocol module. Whereas usually applications issue requests and receive responses, CPTEST lets you type requests and see the responses on the terminal. CPTEST also displays asynchronous messages if the protocol sends them. CPTEST works only with a downloaded CP6100 line. Your input to CPTEST consists of test requests for the protocol module, as well as commands for CPTEST itself (for instance, to start a log file).
CPTEST CPTEST Input Line Format INPUT LINE FORMAT The CPTEST prompt is a tilde (~). You can type one or more commands after the prompt; use a semicolon to separate commands that you enter on the same line. This example shows three CPTEST commands entered one per line: ~LOG TO $s.#LOGFILE ~LINE $PDF8 ~SHOW This example shows the same commands entered on the same line:. ~LOG TO $s.#LOGFILE;LINE $PDF8;SHOW The maximum length for a single input line is 132 characters.
CPTEST CPTEST Input Line Format Requests to the Protocol The most important CPTEST input consists of requests to the protocol module. Each protocol has its own set of requests, as defined in the manual describing the protocol. In a CPTEST SEND or SENDNW command, you supply all the data CPTEST needs to format a request. There is only one difference between the SEND and SENDNW commands.
CPTEST CPTEST Input Line Format Waited and nowaited responses are answers to the SEND and the SENDNW (send no wait) commands, respectively. CPTEST checks for completion of outstanding requests before issuing the command prompt. If a request is complete, CPTEST formats and displays the response. CPTEST also formats and displays completed nowaited responses while waiting for the completion of a waited request. After displaying the completed nowaited response, CPTEST continues waiting for the waited response.
CPTEST Numbers In addition, the following special characters have specific meaning to CPTEST: ~ ' # % %H %B = & Tilde (CPTEST prompt) Single Quote (designates a single ASCII character) Pound Sign (designates a decimal number) Percent Sign (designates an octal number) Percent Sign-H (designates a hexadecimal number) Percent Sign-B (designates a binary number) Equal Sign (specifies the CPTEST expression evaluation command) Ampersand (continues the command line) NUMBERS CPTEST accepts binary, octal, decimal,
CPTEST Operators OPERATORS CPTEST recognizes the following arithmetic operations: + * / (addition) (subtraction) (multiplication) (division) Operations are performed in the following sequence: • Items in parentheses are evaluated first. • Division and multiplication are performed. • Addition and subtraction are performed. • Operations of equal precedence are performed in the order in which they are encounted, moving left to right.
CPTEST CPTEST RUN Command CPTEST RUN COMMAND The syntax of the command to run CPTEST is: ----------------------------------------------------------------| | | RUN CPTEST / [ IN , ] [ OUT ] / | | | | | | | | | | is a source file containing the CPTEST commands. | | | | | | | | | | is the name of the output device that receives the | | listing file. | | | ----------------------------------------------------------------Considerations 1.
CPTEST CPTEST RUN Command CSOURCE contains the following CPTEST commands: LOG TO $s.#LOG LINE $PDF SEND 2, 2, 3, 0, *12"test message times twelve" EXIT 2. To use CPTEST interactively, simply enter CPTEST after the colon prompt, and wait for the CPTEST prompt (~) to appear. Then enter the CPTEST commands. :RUN CPTEST ~LOG TO $S.#LOG ~LINE $PDF ~SEND 2, 2, 3, 0, *12"test message times twelve" ~EXIT 3. You can enter CPTEST commands on the run line.
CPTEST CPTEST Commands CPTEST COMMANDS The following pages contain descriptions of the CPTEST commands in alphabetical order. Each command description includes the syntax rules, the function, and examples.
CPTEST = Command = Command Use the expression evaluation (=) command to convert expressions in one numeric base to another numeric base (for example, to obtain the octal equivalent of a hexadecimal expression) or to obtain the numeric equivalent of a single ASCII character. This command accepts a binary, an octal, a decimal, or a hexadecimal number as input, and displays the equivalent value in the other bases (except binary).
CPTEST = Command Considerations 1. If you enter more than one ASCII character, the command evaluates only the first character and displays an error message stating that the subsequent characters were not evaluated. 2. Because hexadecimal is the default base for input values, you need not precede hexadecimal values with "%H". 3. The command treats uppercase and lowercase letters the same when you use them as base designators. Thus, "%b" is the same as "%B". 4.
CPTEST EXIT Command EXIT Command Use the EXIT command to terminate CPTEST and return control to the calling process (i.e., either the GUARDIAN Command Interpreter or CMI). The syntax of the EXIT command is: ----------------------------------------------------------------| | | EXIT | E | | | ----------------------------------------------------------------- Considerations 1. If you enter commands on the CPTEST run line, you do not have to specify the EXIT command.
CPTEST FC Command FC Command Use the FC command when you use CPTEST interactively. FC (the fix command) allows you to reenter and edit the command line you just entered. The syntax of the FC command is: ----------------------------------------------------------------| | | FC | | | ----------------------------------------------------------------- Considerations 1. When you enter the FC command, CPTEST displays the preceding command line, and a period (".") appears as a prompt below the command. 2.
CPTEST HELP Command HELP Command Use the HELP command to display the help text that provides the syntax for the command you specify. The syntax of the HELP command is: ----------------------------------------------------------------| | | HELP | ALL | | | | | | | | | | is the name of the CPTEST command whose syntax you want. | | | | If you enter ALL, CPTEST lists the syntax for all the | | CPTEST commands, along with a brief description.
CPTEST HELP Command ~HELP LINE LINE { | , CLOSE } OPEN/CLOSE CLIP Line Task via CP^6100 LINE Opens the named LINE task. LINE , CLOSE Closes the current LINE task, if open.
CPTEST LINE Command LINE Command Use the LINE command to open the communication line you specify or to close the line currently open. The syntax of the LINE command is: ----------------------------------------------------------------| | | LINE | , CLOSE | | | | | | | | | | is the logical device name of the line you want | | to use for CPTEST. | | | | | | , CLOSE | | | | closes the communication line you opened with the | | preceding LINE command.
CPTEST LOG Command LOG Command Use the LOG command to open a log file that records all the CPTEST commands you enter with their corresponding responses or to close the current log file. The syntax of the LOG command is: ----------------------------------------------------------------| | | LOG TO | LOG STOP | | | | | | | | | | is the name of the log file. | | | | | | STOP | | | | terminates the logging process.
CPTEST SEND Command SEND Command Use the SEND command to format and send a request to the protocol. You can send byte values, word values, hexadecimal strings, ASCII strings, or specified numbers of repetitions of any of these. The syntax of the SEND command is: ----------------------------------------------------------------| | | SEND , , [, | | [,[*][][]...] ] | | | | | | | | | | is a general arithmetic expression that specifies the | | function.
CPTEST SEND Command ----------------------------------------------------------------| | | | | | | is a general arithmetic expression that specifies how | | many times is to be repeated in the request. | | The expression must evaluate to an integer; include a | | prefix for any number that isn't hexadecimal. | | | | | | | | | | contains additional data needed for the request.
CPTEST SEND Command whether the request completed successfully or in error. To find out the meaning of a status code, consult the manual describing the protocol. The number following the characters "Tout=" is meaningful only in certain protocols; for instance, in ADCCP you ignore this field. If the protocol includes a Status Detail field in its response buffer, the number after "Tout=" is the status detail code.
CPTEST SEND Command Examples 1. This example shows a SEND command consisting of a function (05), a modifier (00), and a Request ID (01). ~SEND 05, 00, 01 CPTEST responds by displaying the information shown below: Resp: F= 5($05) M= 0($00) ReqID= 1($0001) Tout= 0($0000) Tin= 36($0024) 0000 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020 00 00 00 00 ....
CPTEST SEND Command ~SEND 02, 00, 02,40 Resp: F= 2($02) M= 0($00) ReqID= 2($0002) Tout= 0($0000) Tin= 36($0024) 0000 00 00 00 00 02 0E 0C 00 00 32 00 00 01 03 18 00 .........2...... 0010 00 00 00 0A 01 00 ...... Request terminated: 09:19:33:96 Elapsed time: 2 Tics 3. This example illustrates a request that contains a text string and a repetition of a character string. The ampersand is used to extend the command line. SEND C0, 00, F2, FF, & 03, "Text Message.
CPTEST SENDNW Command SENDNW Command Use the SENDNW command to send a nowaited message to the protocol. The message can contain byte values, word values, hexadecimal strings, ASCII strings, or specified numbers of repetitions of any of these. The syntax of the SENDNW command is: ----------------------------------------------------------------| | | SEND , , [, | | [,[*][][]...] ] | | | | | | | | | | is a general arithmetic expression that specifies the | | function.
CPTEST SENDNW Command ----------------------------------------------------------------| | | contains additional data needed for the request. | | Express it as one or more occurrences of any of the | | following: | | | | ^B for a byte value, for example ^B1F | | | | ^W for a word value, for example ^1F2D | | | | <> or "" for an ASCII character string, | | for example or "ABCD".
CPTEST SENDNW Command 5. The maximum length of a single input line is 132 characters. However, you can extend the line by entering the ampersand (&) as a line continuator. 6. The maximum length (using line continuation) for a single command is 2048 characters. 7. The maximum length for the is 2000 characters. Example This example contains both a waited (SEND) request and a nowaited (SENDNW) request.
CPTEST SHOW Command SHOW Command Use the SHOW command to determine the name of the communication line that is currently in use. CPTEST displays the line name on the screen. The syntax of the SHOW command is: ----------------------------------------------------------------| | | SHOW | | | ----------------------------------------------------------------- Examples 1.
CPTEST WAIT Command WAIT Command Use the WAIT command to cause CPTEST to wait (either for completion of a request or for a specified amount of time) before issuing a new prompt. The WAIT command applies only to outstanding requests. The default for the WAIT command is to wait five minutes or until request completion (whichever comes first) before issuing the prompt.
CPTEST WAIT Command Examples 1. In this example, you instruct CPTEST to wait for completion of an asynchronous request or a SENDNW request before issuing the prompt: ~WAIT for RESP 2. In this example, you instruct CPTEST to wait up to 3 tics (3/100ths second) for a response before issuing the prompt: ~WAIT 3 3. This example illustrates the default condition for the WAIT command. CPTEST waits five minutes or for completion of any request (whichever comes first) before issuing the prompt: ~WAIT 4.
CPTEST CPTEST Error Messages CPTEST ERROR MESSAGES Below is a list of the CPTEST error messages. CPTEST error messages indicate errors in the source code or in the commands you enter interactively. CAN'T OPEN 'OUT' FILE ERROR: CPTEST is unable to open the file you designated. is a file system error code. Comma expected This command requires you to enter a comma. COMMAND RESERVED FOR INTERACTIVE USERS You can enter the FC command only when you run CPTEST interactively.
CPTEST CPTEST Error Messages Illegal parameter You entered a parameter that is not appropriate to this command. INPUT FILE ERROR: Error occurred when reading the input line. is a file system error code. Invalid device type: The line you specify must be a CP6100 line. LINE TOO LONG TRUNCATED You entered an input line that exceeds the 132 character maximum. CPTEST truncated your input line to 132 characters and executed the command. This might result in a syntax error.
CPTEST CPTEST Error Messages Syntax error The input line contains a syntax error. Enter HELP , and CPTEST displays the correct syntax for this command. Too many parameters The command contains too many parameters. Enter HELP , and CPTEST displays the correct syntax for this command. Value will not fit into a BYTE The value you entered exceeds one byte in length, which is not permitted. Unknown command CPTEST does not recognize the command you entered.
(This page left intentionally blank)
INDEX 6100 subsystem Advantages of 1-8, 1-12 Components 1-8 Dual-port controllers 2-9 Failures 2-8 Single-port controllers 2-10 ABORT CMI 3-11 Access Exclusive 2-7, A-5 Shared 2-7, A-5 ACTIVATE CMI 3-11 State known to CMI 3-10 ADCCP 1-2 ALTER CIU command 3-24/25, 3-29 ALTER LINE CONFIG 3-13 Effect of 3-15 OPCLASS 3-16 PROGRAM 3-12 ALTER PROCESS command 3-25, 3-29 Application Functions performed 2-1 Application design strategies 1-5 Application error handling 2-7, 2-12 Asynchronous messages 2-6, 2-13
Index BOOT state 3-10 BSC 1-2, 3-34 BSCITBSIZE 3-34 BSCREADTO 3-34 BSCRETRIES 3-34 Burroughs Multipoint Supervisor 1-2 CANCEL call 2-5 Changing SYSGEN parameters 3-8 CLBFRAMESIZE 3-32 CLOSE call 2-5, 2-7, A-6 Cold load Effects on configuration changes 3-13 Processor assignments after 3-7 Communication controllers First generation 1-6 Second generation (6100) 1-8 Communications Line Interface Processor (CLIP) 2-2 Communications Management Interface (CMI) 2-4, 3-8, 3-22 Communications Management Process (CM
Index CONTROLLERS paragraph 3-2, 3-5, 3-7 CP6100 Environment 1-3 Functions performed 2-2, 2-4 How do I use? 1-4 How related to ENVOY and ENVOYACP 1-6 Used to control multiple lines 3-32 What is 1-2 CPTEST B-1 = command B-10 CMI 3-38 Error messages B-29 EXIT command B-12 Expressions B-6 FC command B-13 HELP command B-14 Input line format B-2 LINE command B-16 LOG command B-17 Numbers B-5 Operators B-6 Prompt B-2 Reserved identifiers B-4 Responses from the protocol B-3 RUN command B-7 SEND command B-3, B-18 S
Index Error handling and reporting CP6100 2-7 File system errors defined A-1 Kinds of errors and error reports Levels of errors 2-11 Error trapping and recovery CP6100 2-13 Examining the configuration 3-16 EXCHANGE 1-4 2-11/12 Failures Component 2-8, 3-8 LIU 2-8, 3-8, A-3 Total subsystem 2-8, A-3 Fault-tolerance 6100 subsystem 1-12, 2-4, 2-8 of first generation controllers 1-7 File Configuration 3-2 File management interface 2-4 Typical order of calls 2-7 File system calls 1-4, 2-4/7 File system errors 2-
Index Managing lines 3-1 MAXFRAME 3-33 MAXLOCALAREA 3-32 Memory management CP6100 considerations 3-32, A-8 Microcode Defining to SYSGEN 3-3, 3-5 MPS-Burroughs 1-2 MPS-TINET 1-2 MPSBAUTODISABLE 3-36 MPSBBAUDnnnnn 3-36 MPSBCONTROLCF 3-36 MPSBNOAUTODISABLE 3-36 MPSBNOCONTROLCF 3-36 MPSBPACE 3-36 MPSBPOLLINTERVAL 3-36 MPSBRETRIES 3-36 MPSBTIMEOUT 3-36 MULTI parameter 3-7, 3-32 Multipoint Supervisor-Burroughs 1-2 Multipoint Supervisor-TINET 1-2 NCR Multipoint Protocol NOAUTOSTOP 3-8 NONSTOPON A-3 OPEN call 2-5,
Index Protocol task Functions performed 2-2 Protocols 1-2 Range acceptable to LIU 3-17 READ call 2-6, 2-7, 2-13 Request ID A-3, A-6 Requests Order of 2-7, 2-11 To the file system 2-4 To the protocol 2-5 RESET Operand in CMI CONTROL request 3-11/12 Operand in CMI STATUS request 3-19 Retries (also see L1RETRY, L2RETRY) By protocol task 2-12 RUN state 3-10 Security considerations 3-9 SETMODE call 2-5, 2-7 Single-port controllers 1-8 Configuration issues 3-7/9 Error handling 2-8, 2-10 Introduction to 1-10/11, 1
Index TIAUTODISABLE 3-35 TIBAUDnnnn 3-35 TICONTROLCF 3-35 TINET 1-2 TINET Multipoint Supervisor TINOAUTODISABLE 3-35 TINOCONTROLCF 3-35 TIRETRIES 3-35 TITIMEOUT 3-35 TRACE CMI 3-38 TWA 3-33 Using CP6100: Programming 1-2 2-1 WINDOW 3-33 WRITEREAD buffer 2-5/6 WRITEREAD call 2-5, 2-7, 2-13, A-5 Writing applications that use CP6100 2-1 XRAY 3-22 October 1985 Index-7
