Input/Output Device Driver Reference/Asynchronous (RS232-C) Communications Device Driver

The Asynchronous Communications (ASYNC) device driver enables OS/2 applications to utilize the Serial Communications (RS232-C) device hardware. The physical device driver allows an application program in OS/2 session to support duplex communications while the device driver: The user will normally want to use the physical ASYNC device driver either in conjunction with the spooler (for serial printers only) or with an application program that uses the RS232-enabling capabilities of the physical ASYNC device driver coupled with a serial device attached to the system.
 * Services the RS232-C port in an interrupt-driven manner
 * Provides transmit and receive queues
 * Provides different automatic control modes for the modem control signals
 * Provides logical data stream flow control (XON/XOFF) for transmit and receive operations

The user installs the physical ASYNC device driver by adding a DEVICE= statement to the CONFIG.SYS file.

Hardware Support
The RS232-C ASYNC communications device driver supports any personal computer system based on an 80386SX (or higher) microprocessor.

IBM PS/2 Micro Channel Adapter Support
The physical device driver supports a maximum of four ASYNC ports on a maximum of two different interrupt levels. The interrupt levels must have ABIOS support, with one unit per Logical ID (LID) for the ASYNC Device ID. The only ASYNC devices supported on IBM PS/2 and the Extended Industry Standard Architecture (EISA) machines are COM1, COM2, COM3, and COM4. These devices correspond to the first four LIDs in the ABIOS common data area that have the architected ASYNC Device ID. These devices also correspond to the first four ASYNC addresses in the ROM BIOS 40: data area.

If a device has capabilities other than ASYNC that cannot be utilized independently of the ASYNC capabilities (for example, as in the Advanced BIOS separate LID architecture), and if Advanced BIOS assigns the device the ASYNC Device ID, then that device can be used only for ASYNC in that power-on session.

If the device is assigned the ASYNC Device ID, and it has additional capabilities beyond supporting the RS232-C port (for example, a built-in modem), the physical device driver does not recognize those additional capabilities (and potential limitations). Also, the physical device driver does not inform any application program of those additional capabilities or limitations. In addition, it does not limit the control of the RS232-C interface or the device to only those modes that are acceptable to the extended hardware capabilities of that RS232-C port.

If the device is not assigned the ASYNC Device ID, it is not supported by this physical device driver. If an ASYNC device is not supported by the OS/2 operating system, but is recognized by Advanced BIOS as an ASYNC Device ID, the physical device driver can recognize and try to use that unsupported device, if it is COM1, COM2, COM3, or COM4.

AT Bus Adapter Support
The physical device driver for the IBM AT bus machines by default, supports two ASYNC ports, COM1 and COM2, each on separate levels. ASYNC ports with the following base I/O addresses are recognized by the physical device driver: COM3 and COM4 are supported by the command line parameters for COM.SYS. COM3 and COM4 are supported through parameters on the DEVICE= statement in the CONFIG.SYS file. These parameters specify the desired base I/O address and interrupt levels. The physical ASYNC device driver for the AT-bus machine interfaces directly to the hardware and supports:
 * 3F8H (must generate a level 4 interrupt)
 * 2F8H (must generate a level 3 interrupt)
 * IBM AT-bus serial/parallel adapter based on the NS 16450 Universal Asynchronous Receiver Transmitter (UART) device
 * Other compatible adapters based on the UART architecture (NS 16550, NS 16550A)

Attachment Support
The ASYNC physical device driver does not provide any support for devices attached to the RS232-C port. The physical device driver provides enabling support for the RS232-C interface itself. Application programs, subsystems, and systems programs provide the support needed to use devices attached to the RS232-C port.

The ability to support a device can be determined by understanding the level of RS232-C interface enabling support the physical device driver provides, along with the characteristics of the attachment hardware in question and the required functions to be supported.

The OS/2 operating system provides a mechanism where one or more additional drivers can be installed to support specific COM ports. This feature might be required for the following reasons:
 * To allow an application program to support a special device not adequately supportable with this ASYNC device driver.
 * To allow additional COM ports (besides COM1-4 on IBM PS/2) to be supported.
 * To enhance the level of device driver function for a given COM port. (This might be required for certain subsystem support.)

RS232-C Interface
The ASYNC interface consists of separate read and transmit lines. There are two separate modem control signals whose output values can be controlled by the physical device driver: There are four separate modem control signals whose input values are available to the physical device driver: The receive and transmit data lines have the following hardware characteristics: The modem control signal lines have the following hardware characteristics:
 * Data Terminal Ready (DTR)
 * Request To Send (RTS)
 * Data Set Ready (DSR)
 * Clear To Send (CTS)
 * Data Carrier Detect (DCD), also known as Receive Line Signal Detect (RLSD)
 * Ring Indicator (RI)
 * Logical 1 (Marking). More negative than -3 Volts. This state could mean no data.
 * Logical 0 (Spacing). More positive than +3 Volts. This state could mean break condition.
 * Function ON, when more positive than +3 Volts.
 * Function OFF, when more negative than -3 Volts.

Hardware Support for Extended Hardware Buffering
This capability is a feature of the asynchronous communications port's serial controller device. Serial controllers that support this capability, such as the NS-16550A UART, are present in many IBM PS/2 systems and on a variety of IBM and non-IBM asynchronous communications adapters.

INS 8250, INS 8250-B Considerations
The following hardware defects cannot be compensated for in the physical device driver and can cause indeterminate function when used with the OS/2 physical ASYNC device driver:
 * Line Control Configurations:These devices are known to transmit bad data when configured for 5 data bits and 1.5 stop bits.
 * Receive Character Overrun Errors:These devices are known to occasionally drop received characters without posting the RECEIVE_OVERRUN error flag. Undetected data loss can result from this hardware deficiency. Application error-correction routines can be implemented to ensure accurate data transmission when these devices are being used.
 * Spurious Characters at Power-On:These devices can transmit a single random character at power-on. The connected device must not be expecting valid data to be received until after the physical device driver initialization routine has been run.

Supported Bit Rates on 16450 and Compatibles
The NS 16450 and other compatible UART devices (including the 8250- and 16550-Series UARTs) incorporate a Programmable Baud Generator feature that is driven as a function of the following constants: CLOCK    = 1843200    ; crystal frequency CLOCK/16 = 115200     ; after divider Given these constants, the algorithm for determining which rates are supported is explained in the following examples:
 * If 900 bps is specified, the bit rate is exactly 900 because it divides evenly into 115200 (115200/900 = 128). Bit rate, returned by IOCtl ASYNC_ GETBAUDRATE, is 900.
 * If 901 bps is specified, the bit rate does not change, and the IOCtl fails with an invalid parameter error because it cannot be supported within .01% (115200/901 = 128, 115200/128 = 900, which gives a .1111% error).
 * If 907 bps is specified, the bit rate is 907.0866 because it can be supported within .01% (115200/907 = 127, 115200/127 = 907.0866, which gives a .0095% error). Bit rate, returned by ASYNC_GETBAUDRATE, is 907.
 * If 110 bps is specified, the bit rate is 110.0287, even though the error is over .01% (115200/110 = 1047, 115200/1047 = 110.0287, which gives a . 0260% error). Bit rate, returned by ASYNC_GETBAUDRATE, is 110.


 * Note: Where division is performed and the quotient is not a whole integer, an integer result is obtained by rounding off the fractional part of the quotient.

ASYNC (RS232-C) Device Driver Features
The device driver supports the ASYNC interface in an interrupt-driven manner. This allows the multitasking capabilities of the OS/2 operating system to be supported while ASYNC data reception and transmission are taking place.


 * Warning: With any supported hardware, the physical device driver cannot absolutely guarantee accurate function, as there is a dependency on the hardware being driven. It is known, for example, that INS 8250 and INS 8250-B UART devices exhibit a number of deviations from their hardware specifications. In some cases, these deviations have been compensated for in the physical device driver design. Some of these deviations, however, cannot be resolved in software. The user must be familiar with the limitations and restrictions associated with such hardware.

When data is given to the transmit hardware, it has not yet been physically transmitted (at the RS232 interface). The data is considered completely transmitted by the transmit hardware at the physical RS232 interface when the transmit shift register of the UART is empty. The IOCtl, ASYNC_GETLINESTATUS, which can be found in the OS/2 Physical Device Driver Reference, can be used to determine this information.

The device driver transmit queue is a memory buffer between the operating system and the transmit hardware. The device driver receive queue is a memory buffer between the operating system and the receive hardware. Both are considered to be owned by the physical device driver because the physical device driver controls the data movement in and out of the transmit and receive queues. Algorithms for this data movement can change between releases of the physical device driver. Changes in the ASYNC hardware can cause changes in the data movement algorithms and external interfaces.

Data that applications send (made available by Write requests) is placed in the physical device driver transmit queue. When an interrupt occurs to tell the physical device driver that the hardware is ready for more data, the driver gives the transmit hardware more data from the transmit queue.

When an interrupt occurs to tell the physical device driver that the hardware has received data, that data is placed in the physical device driver receive queue. When the physical device driver gets a Read request (READ request packet) from the application, it fills the Read request from the receive queue.

At high bit rates, such as 19200 bits-per-second, a serial device supporting full-duplex asynchronous I/O can generate an interrupt every 260 microseconds (at 10 bits-per-character and one interrupt-per-character transmitted and received). This leads to excessive interrupt-time overhead in the multitasking, interrupt-driven, device driver.

To address this problem, serial devices with Extended Hardware Buffering capabilities (FIFO or First-In-First-Out buffers) have been developed. However, many serially-attached devices that support the RS232-C interface, have been designed to operate with specific protocols that assume the system processes all data I/O one character at a time. The ASYNC physical device driver employs a software mechanism that automatically controls parameters to utilize the Extended Hardware Buffering capability, while compatibly supporting devices that use existing ASYNC device driver protocols.

The Automatic Protocol Override (system default) mode for Extended Hardware Buffering support partially utilizes only these performance advantages, while remaining fully compatible with the behavior of existing ASYNC device driver protocols (for example, Input Sensitivity using DSR). Applications and subsystems can disable certain device driver default settings in order to fully use the Extended Hardware Buffering capabilities. This results in a significant reduction of serial device interrupt processing overhead, and greatly increases the aggregate bit rates that can be supported across multiple active COM ports.

The size of the receive and transmit queues are available from the following IOCtls: The physical device driver services each communications port independently. Requests issued to a given port have no effect on any other communications ports that the physical device driver might be servicing. The physical device driver processes READ and WRITE request packets independently for a given port. An application can be written to support simultaneous reception and transmission of data. In addition, the device driver can process an IOCtl request simultaneously with outstanding Read and Write requests.
 * Query Number of Characters in Receive Queue (ASYNC_GETINQUECOUNT)
 * Query Number of Characters in Transmit Queue (ASYNC_GETOUTQUECOUNT)

The physical device driver does not schedule the processing of IOCtl requests. It processes the IOCtl request when received, regardless of what else it is doing. This can cause unexpected results if, for instance, the bit rate is modified while data reception or transmission is taking place. The application should issue only one IOCtl request at a time. If it issues another IOCtl request before the first IOCtl request is completed, the results are UNDEFINED.

The device driver queues multiple READ and WRITE request packets independently and always begins processing the READ request packets in the order they are received. It also begins processing the WRITE request packets in the order they are received.


 * Note: The operating system does not guarantee that file system requests will be delivered to a device driver in the order in which they are issued by an application. This means that a request by one thread can get blocked in the operating system, thus allowing a subsequent request by a different thread for the same function (for example, DosWrite) to pass through and arrive ahead of the first thread at the physical device driver. This is true for synchronous operations performed by multiple threads or asynchronous operations performed by the same thread.

Because of thread-priority considerations and the system dynamics, the order observed by the application of completing requests of the same type might not be the order in which they were received by the device driver. The physical device driver always keeps the data in the same order in which the READ and WRITE request packets (of the same type) were received. There is no ordering or timing between different types of request packets.

The concept of a First Level Open is described in the section on. A First Level Open occurs when the device driver receives an OPEN request packet for the port and the port is not already open (from a previous open without a matching close). A CLOSE request packet causing the physical device driver to process the next OPEN request packet as a First Level Open is called a Last Level Close. Because the requests that an application issues sometimes get out of order before they reach the device driver, an application cannot consider a close a Last Level Close until the CLOSE completes. If the application issues an Open request to the COM port before a previously issued Close request is completed, then the results are UNDEFINED.

A Flush request can be completed before all the appropriate request packets (which have been queued by the device driver) have been flushed. The appropriate request packets eventually are flushed and return to the caller, based on their priority and the system dynamics. Once the Flush request has been processed, the appropriate request packets do not cause data to be incorrectly transmitted (or received data to be moved).

The device driver supports different timeout processing characteristics and timeout settings for the Read and Write requests. Only the physical device driver is informed of when a given character is being transmitted or received at the hardware interface. Therefore, an application cannot expect to provide real-time flow control of data (in the middle of data transmission or reception) based on logical characters (XON/XOFF), or based on the state of the modem control signals by manually: Alternatively, the physical device driver provides optional modes of operation to control the data flow through the RS232-C port automatically. OS/2 applications use IOCtls to select which protocols are to be made active.
 * Controlling or monitoring those modem control signals
 * Monitoring the queue status
 * Monitoring data moving across the link

Output Modem Control Signals
In addition to allowing the application to directly control RTS and DTR, the physical device driver has different automatic control modes to control the value of the output modem control signals: These control modes are described in the section on, and in the IOCtls description.
 * Open and Close processing of DTR and RTS
 * Disable/Enable DTR and RTS
 * RTStoggling on transmit
 * Input handshaking using DTR and RTS


 * Note: The level of support provided by this device driver requires that DTR and RTS are turned on at least once, even if this puts the physical device driver in a mode where they will never be turned on again.

Input Modem Control Signals
Besides allowing the application to read directly the current state of DSR, CTS, DCD, and RI, the physical device driver has automatic modes that cause it to respond to the value that some input modem control signals can have: These control modes are described in the section on and in the IOCtls description. Additional information on the state of the input modem control signals is available by using the IOCtl ASYNC_GETCOMMEVENT.
 * Output handshaking using CTS, DSR, DCD
 * Input sensitivity using DSR

Logical Flow Control (XON/XOFF)
The application can attempt to manually control the flow of data by using the following IOCtls: The physical device driver automatically controls the flow of transmitted data based upon the reception of XON/XOFF characters. This is referred to as Automatic Transmit Flow Control (XON/XOFF). The physical device driver also attempts to control the flow of data that is received by automatically transmitting XON/XOFF characters to the system it is communicating with, based on the amount of space left in the receive queue. This is referred to as Automatic Receive Flow Control (XON/XOFF).
 * Transmit Immediate (ASYNC_TRANSMITIMM)
 * Stop Transmit Behave as if XOFF Received (ASYNC_STOPTRANSMIT)
 * Start Transmit Behave as if XON Received (ASYNC_STARTTRANSMIT)

Support for Extended Hardware Buffering
Another significant feature of this device driver is its exploitation of the Extended Hardware Buffering capabilities of the serial communications devices in many IBM systems and option adapters. Extended Hardware Buffering refers to the ability of the serial device servicing a COM port to buffer in hardware several characters, and to release them all at one time on the occurrence of a single transmit or receive hardware interrupt. This capability significantly reduces the interrupt-driven I/O processing overhead required to service Transmit and Receive requests on a given COM port. On the devices that support the Extended Hardware Buffering capability, this significantly improves COM I/O throughput and improves data integrity for higher data-transfer rates.

The Extended Hardware Buffering capabilities are automatically controlled under the default modes of the physical ASYNC device driver. Automatic Protocol Override is a feature of the OS/2 ASYNC device driver that automatically controls parameters relating to Extended Hardware Buffering. Systems and Adapters that incorporate the FIFO-mode hardware feature in a manner fully compatible with the NS-16550A UART are automatically enabled to run in Automatic Protocol Override mode.

Line Characteristics
IOCtls can be used to control and read the bit rate, number of stop-bits per character, number of data bits per character, and the parity characteristics of the line. See.

Break and Error Processing
The device driver can be commanded to transmit a Break with an IOCtl (ASYNC_SETBREAKON and ASYNC_SETBREAKOFF). An application can detect where an error or break occurred in the input data stream by using Break Replacement Character Processing and Error Replacement Character Processing. This requires that certain binary byte combinations be reserved for this purpose.

State of the COM Port
The following IOCtls can be used to determine the state of the COM port or if a given event happened. However, the exact timing relationship between this information and the specific data being received or transmitted at the time of the event is not available.


 * Query COM Event Information (ASYNC_GETCOMMEVENT)
 * Query COM Status (ASYNC_GETCOMMSTATUS)
 * Query COM Error (ASYNC_GETCOMMERROR)

Event Notification
The device driver does not provide any capabilities of event notification. For example, the only way for an application to know that RI changed state or that a Break condition occurred is to poll that status with the IOCtl ASYNC_GETCOMMEVENT. This should not be a problem for those applications that can use the automatic control modes of the physical device driver during the course of a communications dialog (for time-critical control functions). Polling could be adequate for non-time-critical event monitoring.

Error Alert Generation
The ASYNC physical device driver supports SNA Generic Alerts by generating Error Alerts, as defined under the OS/2 Logging Facility. Alerts are generated by the ASYNC driver whenever the OS/2 Logging Facility is enabled by the user at system initialization time.

Alerts may be generated only while the COM port is open and is processing a Write request (transmitting data). Write Timeout mode must be normal. (If Infinite Timeout mode is enabled, timeouts do not occur.) Error Alerts can be generated only when a Write Timeout occurs while waiting for: Refer to the Set Device Control Block (DCB) Parameters Note on the IOCtl ASYNC_SETDCBINFO which can be found in the OS/2 Physical Device Driver Reference.
 * CTS to be asserted, when Transmit is disabled because CTS is inactive. The Output Handshaking Using CTS mode must be enabled for this alert-generating condition to occur. This mode is enabled by default in the physical ASYNC device driver.
 * DSR to be asserted, when Transmit is disabled because DSR is inactive. The Output Handshaking Using DSR mode must be enabled for this alert-generating condition to occur. This mode is enabled by default in the physical ASYNC device driver.
 * DCD to be asserted, when Transmit is disabled because DCD is inactive. The Output Handshaking Using DCD mode must be enabled for this alert-generating condition to occur. This mode must be enabled by an application. It is not enabled by default in the ASYNC device driver.
 * An XON to be received, when Transmit is disabled because an XOFF is received. Automatic Transmit Flow Control mode must be enabled for this alert-generating condition to occur. This mode must be enabled by an application. It is not enabled by default in the ASYNC device driver.

States of the ASYNC Device Driver
The different processing states of the physical ASYNC device driver, the ASYNC hardware, and the ASYNC control signals are listed below: Each of the above states are covered as follows:
 * Automatic Receive Flow Control (XON/XOFF)
 * Automatic Transmit Flow Control (XON/XOFF)
 * Bit Rate
 * Break Replacement Character
 * Break Replacement Character Processing
 * COM Event WORD and COM Error WORD
 * Data Bits
 * DTR and RTS
 * DTR Control Mode
 * Error Replacement Character
 * Error Replacement Character Processing
 * Extended Hardware Buffering
 * Input Sensitivity Using DSR
 * Null Stripping
 * Output Handshaking Using CTS, DSR, DCD
 * Parity
 * RTS Control Mode
 * Read Timeout State
 * Read Timeout Value
 * Stop Bits
 * Transmit Immediate
 * Transmitting Break
 * Write Timeout State
 * Write Timeout Value
 * XON/XOFF Characters
 * A brief description.
 * The initial (default) value.
 * The effect on the physical device driver when the physical device driver receives an OPEN request packet for the port and the port is not already open (from a previous OPEN without a matching CLOSE). This is called a First Level Open. If applicable, the way the state of the physical device driver is affected by a CLOSE request packet.
 * How the MODE utility can be used to alter the state of this item or how the MODE utility will alter the state of this item.
 * The effect on the physical device driver of the state of Extended Hardware Buffering. In particular, special considerations relating to Automatic Protocol Override are given where the protocol being described is affected by this feature of the physical ASYNC device driver.

Automatic Receive Flow Control (XON/XOFF)
When the physical device driver is enabled for this mode of operation, it transmits an XOFF when its receive queue gets close to full, and an XON when its receive queue is about half full.

The normal mode of Automatic Receive Flow Control causes the ASYNC device driver to stop transmitting all data after it sends an XOFF character until its receive queue lowers to about half full, when it sends the XON character. This behavior is suitable for most devices, but reduces transmit throughput significantly in Full-Duplex (Transmit and Receive) communications scenarios. By setting the Full-Duplex mode of Automatic Receive Flow Control, the physical ASYNC device driver continues to send application data after it sends the XOFF character. See IOCtl ASYNC_ SENTDCBINFO which can be found in the OS/2 Physical Device Driver Reference.
 * Initial Value:Automatic Receive Flow Control is disabled.
 * First Level Open:There is no effect on whether the physical device driver is enabled or disabled for this mode of operation. The state of the physical device driver is reset to show that the last flow control character automatically transmitted was an XON, if it is enabled for this mode of operation.
 * Close Considerations:If the last character automatically transmitted by the physical device driver was an XOFF and a CLOSE request packet is received, the physical device driver automatically transmits an XON, if possible. After processing this close request, the port is not open any more from another open without a close.
 * Mode Utility:Always disables Automatic Receive Flow Control.

Automatic Transmit Flow Control (XON/XOFF)
When the physical device driver is enabled for this mode of operation, it stops sending data to the transmit hardware when an XOFF is received, and resumes sending data to the transmit hardware when an XON is received.

If this mode is enabled, Error Alerts can be generated when the OS/2 Logging Facility is enabled. If an external device sends an XOFF, but does not send an XON, transmission of data is blocked because the device driver is waiting for the XON to be received. If the XON is not received before the Write Timeout period expires, an Error Alert is generated.
 * Initial Value:Automatic Transmit Flow Control is disabled.
 * First Level Open:There is no effect on whether the physical device driver is enabled or disabled for this mode of operation. The state of the physical device driver is reset to show that it has not received an XOFF, so it can transmit (due to automatic transmit flow control), if it is enabled for this mode of operation.
 * Mode Utility:User interface to enable/disable this mode of the physical device driver.
 * Automatic Override:When Automatic Transmit Flow Control is enabled, the physical device driver responds to receiving the XOFF within a single character time. That is, Automatic Protocol Override controls the Extended Hardware Buffering capability so that only one character is buffered for transmit at a time, and the device generates an interrupt for every character received (Receive Trigger Level is set to 1).

Bit Rate
The bit rate determines the hardware setting for the data transfer rate, specified in bits per second, and is the speed for which the hardware is configured. See IOCtls ASYNC_SETBAUDRATE and ASYNC_GETBAUDRATE, which can be found in the OS/2 Physical Device Driver Reference.
 * Initial Value:1200 bps
 * First Level Open:No effect
 * Mode Utility:User interface to change the bit rate

Break Replacement Character
The device driver uses this character value if Break Replacement Character Processing is enabled. See IOCtl ASYNC_SETDCBINFO, which can be found in the OS/2 Physical Device Driver Reference.
 * Initial Value:00h
 * First Level Open:Reset to 00h
 * Mode Utility:No effect

Break Replacement Character Processing
If Break Replacement Character Processing is enabled and the device driver detects a break condition, it places the break replacement character in the physical device driver receive queue. If Break Replacement Character Processing is disabled, the physical device driver does not place any character in the physical device driver receive queue when it detects a break condition.
 * Initial Value:Break replacement character processing is disabled.
 * First Level Open:Break replacement character processing is disabled.
 * Mode Utility:No effect.

COM Event WORD and COM Error WORD
These two WORDs have bits that show the status of the COM port. When an event occurs, the appropriate bits are turned on. The bits are cleared when the WORD is read with the appropriate IOCtl. See IOCtls ASYNC_GETCOMMEVENT and ASYNC_GETCOMMERROR, which can be found in the OS/2 Physical Device Driver Reference.

Data Bits
This is the number of bits contained in each character transmitted or received by way of the communications hardware. See IOCtls ASYNC_SETLINECTRL and ASYNC_GETLINECTRL, which can be found in the OS/2 Physical Device Driver Reference.

DTR and RTS
This is the value of the modem control signals Data Terminal Ready (DTR) and Request To Send (RTS) put out by the communications hardware. Each signal is controlled independently and can be either ON or OFF. See IOCtls ASYNC_SETMODEMCTRL and ASYNC_GETMODEMOUTPUT, which can be found in the OS/2 Physical Device Driver Reference.

DTR Control Mode
The control modes for DTR are: The Enable and Disable control modes of DTR affect DTR processing during a First Level Open. When these control modes are set through the ASYNC_SETDCBINFO, the value of the DTR signal can be modified immediately by the physical device driver. The action depends on the previous control mode of DTR and the current value of the DTR modem control signal. If the control mode of DTR is Input Handshaking, then the device driver controls the DTR signal, depending on how full the receive queue is. The bits that control these states of the device driver are in the device control block.
 * Enable
 * Disable
 * Input Handshaking

Error Replacement Character
The character value that the physical device driver uses, if Error Replacement Character Processing is enabled.

Error Replacement Character Processing
The processing that the physical device driver performs when a received character has an error (parity, framing, overrun, or lack of receive queue space) is determined by whether Error Replacement Character Processing is enabled (active).

Extended Hardware Buffering
The extended hardware buffering (FIFO-mode) capabilities available in supported systems apply to the NS-16550A UART device and other fully compatible devices. These serial devices are installed on many IBM PS/2 system boards, and on various ASYNC communications adapter options. Refer to.

On those systems that incorporate serial devices that fully and compatibly support Extended Hardware Buffering, the OS/2 ASYNC device driver provides three modes for exploiting this feature: The default is to enable Automatic Protocol Override on that COM port. Automatic Protocol Override is an asynchronous device driver mode of operation that automatically controls various parameters of Extended Hardware Buffering, such as Receive Trigger Level and Transmit Buffer Load Count.
 * Enabled
 * Disabled
 * Automatic Protocol Override

Automatic Protocol Override causes the Receive Trigger Level and Transmit Buffer Load Count to be adjusted according to the device driver handshaking protocols in effect. When Automatic Protocol Override mode is ON and the handshaking protocols are set to their default settings, the physical device driver partially exploits only the performance advantages of Extended Hardware Buffering. The default handshaking protocols are: If both Input Sensitivity Using DSR and Output Handshaking Using CTS and DSR are disabled, the Automatic Protocol Override causes the asynchronous device driver to automatically reset internal parameters (fully exploiting the Extended Hardware Buffering capabilities to the maximum extent possible).
 * Enabled for Input Sensitivity Using DSR
 * Enabled for Output Handshaking Using CTS and DSR
 * Disabled for Output Handshaking Using DCD
 * Disabled for Automatic Transmit Flow Control

The physical device driver's initialization default is to set Extended Hardware Buffering capabilities to the Automatic Protocol Override mode. An application or subsystem can alternatively set Extended Hardware Buffering to DISABLED, which causes the hardware to service transmit and receive interrupts one character at a time. It can also set Extended Hardware Buffering to ENABLED, which causes the physical device driver to set certain Extended Hardware Buffering parameters to specified levels, so the serial device fully exploits its Extended Hardware Buffering capabilities to the maximum extent possible.

When Extended Hardware Buffering is set to ENABLED, the following serial device hardware capabilities are exploited for maximum performance benefit and increased receive data integrity: If the physical device driver receives an Open request for a COM port that is not already open, it does not alter the Extended Hardware Buffering setting that is in effect at the time. The ASYNC physical device driver preserves this state across multiple Open and Close requests.
 * By setting the Transmit Buffer Load Count to 16, up to 16 characters are placed in the transmit hardware buffer (FIFO) during the processing of one Transmit Holding Register Empty (THRE) interrupt.
 * A 16-character receive hardware buffer (FIFO) is available with the Receive Trigger Level set to 1, 4, 8, or 14 characters. The Receive Trigger Level determines when the receive hardware generates a Receive Data Available hardware interrupt.

Input Sensitivity Using DSR
When the physical device driver is enabled for this mode of operation and DSR is OFF, the physical device driver discards receive data.

Null Stripping
If the physical device driver is enabled for null stripping, characters read in from the receive hardware (nonerror or nonbreak) with a value of 00h are thrown away. These null characters are stripped (not checked for Automatic Transmit Flow Control), even if the XON or XOFF character has been set to 00h, and are not placed in the physical device driver receive queue.

Output Handshaking Using CTS, DSR, DCD
This mode of the physical device driver can be controlled independently for each modem control signal. When this mode is enabled, the physical device driver does not give data to the transmit hardware if the modem control signals are OFF (disabled). Data is not transmitted unless all the lines enabled for output handshaking are up.

If one of these modes is enabled, Error Alerts might be generated when the OS/2 Logging Facility is enabled. If an external device causes CTS, DCD, or DSR to become inactive, transmission is blocked while the device driver waits for the respective line to become active again. If the line does not become active before the Write Timeout period expires, an Error Alert is generated.

Parity
Determines whether a parity bit exists and, if appropriate, what algorithm determines its value. See ASYNC_SETLINECTRL and ASYNC_GETLINECTRL, which can be found in the OS/2 Physical Device Driver Reference.
 * Initial Value:Even parity
 * First Level Open:No effect
 * Mode Utility:User interface to change the parity characteristics

RTS Control Mode
The control modes for RTS are: The Enable and Disable control modes affect RTS processing during a First Level Open. When these control modes are set using the ASYNC_SETDCBINFO, the value of the RTS signal can be immediately modified by the physical device driver. The action depends on the previous control mode of RTS and the current value of the RTS modem control signal. If the control mode of RTS is Input Handshaking, the device driver controls the RTS signal, depending on how full the receive queue is. If the control mode of RTS is Toggling on Transmit, then the physical device driver controls the RTS signal, depending on whether it is transmitting data. The bits that control these states of the physical device driver are in the device control block.
 * Enable
 * Disable
 * Input Handshaking
 * Toggling on Transmit
 * Initial:Value Enable
 * First Level Open:No effect
 * Mode Utility:User interface to change the RTS Control Mode of the physical device driver

Read Timeout State
When the physical device driver processes a READ request packet, it can be with Normal, No-Wait, or Wait-For-Something Timeout processing. With Normal Timeout processing, if no data is received in the specified period of time, the request is completed. With No-Wait Timeout processing, the request obtains whatever data is available in the physical device driver receive queue (at the time the request is processed by the device driver) and returns. With Wait-For-Something Timeout processing, the request acts like No-Wait Timeout processing. However, if no data is available when the device driver processes the request, the physical device driver waits until some data is available or until the request times out due to Normal Timeout processing.
 * Initial Value:Normal Read Timeout processing
 * First Level Open:The device driver is set to Normal Read Timeout processing
 * Mode Utility:No effect

Read Timeout Value
The user-specific value, in .01 seconds units (based on 0, where 0 = .01 seconds), is used for the Read Timeout processing, if Normal Read Timeout or Wait For Something Timeout processing is enabled.
 * Initial Value:1 minute
 * First Level Open:Set to 1 minute
 * Mode Utility:No effect

Stop Bits
Determines the number of stop bits associated with each character transmitted or received by way of the communications hardware.
 * Initial Value:1 stop bit
 * First Level Open:No effect
 * Mode Utility:User interface to change the number of stop bits

Transmit Immediate
The device driver can be told to transmit a byte immediately, bypassing the normal file system Write requests (bypassing the data to be transmitted in the transmit queue). Only one character at a time can be waiting to be transmitted immediately.
 * Initial Value:There is no character waiting to be transmitted immediately.
 * First Level Open:There is no character waiting to be transmitted immediately.

Close Considerations A CLOSE request packet, when after processing this close request the port is not open any more (from another open without a close), causes the device driver to attempt to transmit the character waiting to be transmitted immediately. If the physical device driver cannot transmit the character waiting to be transmitted immediately (see IOCtl Category 01h ASYNC_TRANSMITIMM), which can be found in the OS/2 Physical Device Driver Reference, it does not try to transmit the character and proceeds with the close processing.

Mode Utility Not applicable.

Transmitting Break
The device driver can be transmitting a break. See IOCtls ASYNC_SETBREAKON and ASYNC_SETBREAKOFF, which can be found in the OS/2 Physical Device Driver Reference.

Initial Value Not transmitting a break.

Close Considerations A CLOSE request packet, when after processing this close request the port is not open any more (from another open without a close), causes the device driver to tell the hardware not to transmit a break any more.

Mode Utility Not applicable.

Write Timeout State
When the physical device driver processes a WRITE request packet, it can be with Normal or Infinite Timeout processing. With Normal Timeout processing if no data is given to the transmit hardware within a specified amount of time, the request is completed. With Infinite Timeout processing, the request is completed only when all the data from the request has been given to the transmit hardware.

Error Alerts can be generated on the occurrence of Write Timeout, if the OS 2 Logging Facility is enabled. In order for an error alert to be generated by the physical ASYNC device driver, the appropriate mode of operation must be enabled.
 * Initial Value:Normal Write Timeout processing
 * First Level Open:No effect on Write Timeout processing
 * Mode Utility:User interface to set Infinite or Normal Write Timeout processing

Write Timeout Value
The user-specific value, in .01 seconds units (based on 0, where 0 = .01 seconds), is used for the Write Timeout processing, if Normal Write Timeout processing is enabled.
 * Initial Value:1 minute
 * First Level Open:Set to 1 minute
 * Mode Utility:No effect

XON/XOFF Characters
The characters used for automatic transmit and automatic receive flow control.
 * Initial Value:XON is 11h, and XOFF is 13h
 * First Level Open:The XON and XOFF characters are reset to their initial values
 * Mode Utility:No effect

Reserved Device Names (COM1-n)
The device name AUX does not appear in the device header of the ASYNC device driver. The ASYNC physical device driver does not support the reserved name AUX for either DOS applications or OS/2 applications.

IBM PS/2 (with Micro Channel) Considerations for COM1-4
The IBM PS/2 ASYNC device driver has device names COM1, COM2, COM3, and COM4 in its device driver header. Device name COM1 corresponds to the first LID in the ABIOS common data area with the ASYNC Device ID. Device name COM2 corresponds to the second LID. Device name COM3 corresponds to the third LID. Device name COM4 corresponds to the fourth LID in the ABIOS common data area with the ASYNC Device ID.

The Advanced BIOS architecture ensures that the ordering in the ROM BIOS 40: data area matches the ordering of the LIDs in the common data area. Compatibility BIOS supports up to four ASYNC devices on the IBM PS/2 system, and the physical device driver assumes that the order of the Logical IDs matches the order of the addresses of these devices in the ROM BIOS 40: data area. Additional ASYNC devices can be supported by additional device drivers.

The mapping of the ASYNC Logical ID ordering to COMn must be consistent across all device drivers that support the ASYNC hardware in the IBM PS/2 hardware environment.

Initialization/Resource Management
The device driver is loaded and initialized with a DEVICE= statement in the CONFIG.SYS file. They physical device driver processes parameters on the CONFIG.SYS to support COM ports with nonstandard address and IRQ's. Type help com.sys and read about the parameters.

During initialization, the physical device driver attempts to free memory from its data segment for ports it does not need and that do not get initialized. The physical device driver does not remove device names from its device driver header for ports that do not get initialized.

The device driver does not deinstall a device if the system requests it. If another device driver wishes to support a port already supported by this device driver, it needs to be initialized before this ASYNC device driver.

Shared ownership of a given serial device between multiple device drivers in a single session of the OS/2 operating system is supported, subject to certain restrictions. Each driver that installs sharing a serial device obtains exclusive access to that device when it processes an Open request, rather than claiming the device during initialization. Each driver also fully relinquishes control of that device, when it processes a matching Close request.

When the physical device driver is initialized, it is enabled by default for Output Handshaking Using CTS and DSR. This is for compatibility with existing systems (IBM PC and PS/2 BIOS INT 14H) and the requirements of supporting an RS232 port. It is also enabled by default for Input Sensitivity to DSR. This allows a remote device to indicate whether data being received is valid and is enabled to help ensure compatibility with existing systems. The initialization default for Extended Hardware Buffering on serial devices that fully support FIFO mode operations is Automatic Protocol Override.


 * Note: The ASYNC device driver default protocols provide an upwardly compatible RS232-C interface for communication with most devices. New communication applications and devices might not require the default protocols to be enabled. The user should evaluate these alternatives and consider which protocols to enable or disable in order to provide the highest possible performance for support of a given serial device.

Initialization Considerations
The device driver does not attempt to initialize or support a port if it does not get the INIT request packet for the port's corresponding device name. If the physical device driver gets the INIT request packet for a given device name, it checks to see if a valid I/O address is in the BIOS 40: data area that corresponds to that device name. COM1 is in 40:0 and COM2 is in 40:2. If the 40: area does not have a valid I/O address, the physical device driver fails the port and will not support the port. Otherwise, the device driver attempts to get exclusively the interrupt level that corresponds to the I/O address for the port. If the interrupt level is not available, the physical device driver fails to initialize the port and will not support the port.

If the interrupt level is available, the physical device driver relinquishes the interrupt level. The physical device driver also initializes the port and sets up support for the port during this startup of the operating system.

In summary, in order for the physical device driver to support a port, the following must be TRUE: The physical device driver claims ownership of the port by not deinstalling the corresponding device name. Another device driver can cause this device driver not to claim a port by initializing before this device driver, and by doing at least one of the following:
 * The device driver must get an INIT request packet for the device name.
 * The 40: area that corresponds to the device name must have a valid I/O address.
 * The appropriate interrupt level must be available for exclusive use, even though the physical device driver will not claim the interrupt level for exclusive use during initialization.
 * Not allowing this physical device driver to receive an INIT request packet for a given device name
 * Putting an invalid I/O address in the corresponding 40: area (for example, 0)
 * Exclusively owning the appropriate interrupt level at initialization time

The device driver does not attempt to initialize or support a port if it does not get the INIT request packet for the port's corresponding device name. If the physical device driver gets the INIT request packet for a given device name, it attempts to claim ownership of the specific LID position for the ASYNC Device ID that corresponds to the device name being initialized.

For Micro Channel bus machines, if the LID is not available, the physical device driver fails to initialize the port and does not support the port. If the LID is available, the physical device driver initializes the port and sets up support for the port during this startup of the operating system. The LID for the port is relinquished; it is reclaimed during Open processing.

For the AT-bus machine, COM.SYS still installs even though the LID is not present.

In summary, for the physical device driver to support a port on an IBM PS/2 computer, the following must be TRUE: The physical device driver claims ownership of the port by not deinstalling the corresponding device name. Another device driver can cause this device driver not to claim a port by initializing before this device driver and doing at least one of the following:
 * The physical device driver must get an INIT request packet for the device name.
 * The ASYNC LID corresponding to the device name must be available.
 * Not allowing this device driver to receive an INIT request packet for a given device name.
 * Claiming the appropriate ASYNC LID.

Data Translation/Monitor Support/Spooler Support
The physical device driver provides no data translation, code page, or monitor support. It is the responsibility of the application or subsystem to provide any function required in these areas.

Spooling from LPT to COM is supported by the spooler, but spooling from COM to LPT, or COM to COM, is not supported. When spooling from COM to LPT, code page support is provided by the spooler.

Any requests for registering or opening a monitor chain to COMn are rejected by the physical device driver. The physical device driver deals with binary data and provides no special processing of binary or ASCII data streams.

ASYNC Communication Device Driver Interfaces
The physical ASYNC device driver supports a large set of generic IOCtl functions (Category 01h), which are organized into the following groups:
 * Break Processing
 * Device Control Block (DCB) Parameter Access
 * Device Driver I/O Queue Management
 * Line Characteristics
 * Manual XON/XOFF Processing
 * Polled Event Functions

File System Requests
The physical ASYNC device driver supports the File System requests as shown in the following table.

Open Processing
The physical device driver does not claim the interrupt level the port is on until the port is open. If the interrupt level is not available, the OPEN request packet fails. The interrupt level is claimed exclusively on the ISA bus machines. The interrupt level is claimed shareable on the Micro Channel architecture machines.

On PS/2 machines, a First Level Open causes the physical device driver to attempt to obtain a Logical ID. If this fails (which indicates another physical device driver might be using the device), a general failure is returned. If the Logical ID is obtained, but the open fails for some other reason, the Logical ID is freed. Other physical device drivers that coexist with the OS/2 physical ASYNC device driver perform similar processing.

If a timer tick handler is not available during First Level Open processing, the Open request can fail. If the physical device driver receives an OPEN request packet and the COM device is not already open (from a previous open without a close), this is called a First Level Open, and the physical device driver does special processing. See. If a subsequent Open request is issued before a previous First Level Open request has completed, the device driver might process the OPEN request packets in an order different from the one in which they were issued. This could cause the First Level Open to take effect at a time different from what the application expected.

An Open request should never be issued until a previous Last Level Close request has completed. Otherwise, the function performed by a Last Level Close and a First Level Open might not occur. If the port is not already open (First Level Open), the physical device driver attempts to clear out any data in the receive hardware. On the IBM PS/2 system, if the port is not already open (First Level Open), the physical device driver relies on the Reset/Initialize Advanced BIOS function to reset and clear the UART receive hardware.

Close Processing
An application should never close an open handle to a COM port while there are requests still pending for that handle. If a request has not completed, it might be waiting for timeout processing. IOCtls are used to determine, and change, the current timeout processing.

A Last Level Close occurs when the port is no longer open (from another open without a close). When a Last Level Close occurs, the physical device driver does some special processing:
 * Clears the receive and transmit queues
 * Turns break OFF, if it is currently transmitting a break
 * Clears any character waiting to be transmitted immediately, if it cannot be transmitted If it can be transmitted, the physical device driver makes sure that it is given to the transmit hardware
 * Attempts to automatically transmit an XON (if possible), if currently enabled for Automatic Receive Flow Control (XON/XOFF), and the last character that the physical device driver automatically transmitted was an XOFF
 * Waits until all the data in the transmit hardware has been physically transmitted
 * Relinquishes the interrupt level
 * Turns DTR and RTS OFF, if they are not already OFF. The physical device driver first waits the specified number of character times
 * Relinquishes the Logical ID for the device (on PS/2 machines)

Read Processing
The physical device driver begins processing Read requests in the order it received them. Notice that this might not be the same order in which the requests were issued by the application. If the physical device driver receives more than one Read request, the request is queued on the Read request queue for later processing. Applications might not see Read requests completed in the order in which they were issued. The order of the data placed in the Read requests reflects the order in which the requests were received by the physical device driver.

The data for the Read requests comes from the physical device driver receive queue. Because of timeout processing, it is normal for the total number of Read characters requested not to be read. This is not considered an error. The request is completed when timeout is completed or when the amount of data requested is placed in the Read buffer. The various kinds of Read Timeout processing are discussed in the. To reduce the probability of a device driver receive queue buffer overrun, the communications protocol takes into account the size of the physical device driver receive queue.

Write Processing
The physical device driver begins processing Write requests in the order it received them. Notice that this might not be the same order that the requests were issued by the application. If the physical device driver receives more than one Write request, the request is queued on the Write request queue for later processing. Applications might not see Write requests complete in the order they were issued. The order of the data transmitted due to the Write requests reflects the order that the requests were received by the physical device driver.

The data from the Write requests is placed in the physical device driver transmit queue. The number of characters written is considered to be the number of characters given to the transmit hardware, and not the number of characters placed in the physical device driver transmit queue. Because of timeout processing, it is possible that the total number of Write characters requested will not be transmitted. This is not considered an error. The request is completed when it times out or when the amount of data requested is given to the transmit hardware (but not actually transmitted at the physical RS232-C interface). Write Timeout processing is discussed in.

If infinite Write Timeout processing is enabled, it is the responsibility of the application to monitor the status of the Write requests. The application might have to issue an IOCtl to disable infinite Write Timeout processing to cause the Write request to be completed (without all the data being transmitted). If an application does not check that all the data is given to the transmit hardware on each Write request, use the infinite timeout processing mode of the physical device driver to ensure that all the data has been given to the transmit hardware before the request is completed. To increase the throughput (ratio of number of characters transmitted per second to the bit rate), the application should keep the Write requests as large as possible.

Access Authorization
The physical ASYNC device driver does not prevent multiple processes from concurrently opening the same device name. The physical device driver uses standard file system contention control. An application or subsystem that needs exclusive access to the COM device will open it with access rights set to DENY_ANY. Inheritance of open handles, and sharing of the device among multiple opens, works in a manner similar to regular files.

ASYNC (RS232-C) Generic IOCtl Command Summary
The following table lists each function and its description: See "Generic IOCtl Commands", which can be found in the OS/2 Physical Device Driver Reference, for detailed descriptions of the asynchronous Category 01h IOCtl functions.
 * Note: Device Control Block parameters determine:
 * Automatic Transmit Flow Control (start/stop transmit, when XON/XOFF received)
 * Automatic Receive Flow Control (transmit XON/XOFF, when receive buffer fills/empties)
 * XON/XOFF Characters
 * DTR Control Mode (enable/disable/input handshaking)
 * RTS Control Mode (enable/disable/input handshaking/toggling on transmit)
 * Output Handshaking Using CTS/DSR/DCD (control signal determines when to transmit)
 * Input Sensitivity Using DSR (reception of data controlled by DSR)
 * Error Replacement Character and Processing
 * Break Replacement Character and Processing
 * Null Stripping
 * Timeout Processing
 * Extended Hardware Buffering (DISABLED/ENABLED/Automatic Protocol Override)

DOS Session Considerations/Restrictions
Applications using a serial printer from a DOS session must spool print data to the spooler through the appropriate LPT handles.

The physical device driver makes no attempt to restrict or mold the function of file system requests because they might have come from a DOS session. To achieve the full capabilities of the file system access to COM, the application needs access to the full range of Category 01h IOCtls. The design and externals of the physical asynchronous device driver are based on the requirements of OS/2-mode applications that use the RS232-C port of the system.

Spooler Considerations
When setting up a serial printer in the Serial Port Settings, the user can choose between two handshaking protocols. If the user selects None, the serial printer card switches must be set for XON/XOFF handshaking. If the user chooses Hardware, the serial printer card switches must be set for DTR Pacing.

Performance
The achievable performance is very sensitive to the environment. The type and amount of other system activity determine the achievable performance. On the IBM PS/2 system, the number of COM ports or other devices on the same interrupt level significantly affects the achievable performance level.

Trying to receive data at too high a bit rate could cause hardware overrun errors or receive queue overrun errors. Receive queue overrun errors are easily solved by adjusting the communications protocol to the size of the physical device driver receive queue. Trying to transmit data at too high a bit rate could also cause the performance of the operating system to be severely reduced.

The bit rate can be set with the MODE command or with an IOCtl. The bit rate should not be set to values that might cause receive overruns or adverse OS/2 system performance effects.

Enabling Extended Hardware Buffering
In most transmit-only situations (for example, serial printers), there is always a requirement for flow control (using Output Handshaking or Automatic Transmit Flow Control). If the attached hardware can receive a significant number of characters after the modem control (pacing) signal is changed, then setting Extended Hardware Buffering to enabled (ASYNC_SETDCBINFO) can be an acceptable way to significantly improve the transmit throughput and the operating system performance. This allows the Extended Hardware Buffering to yield maximum serial I/O performance while still providing the required Output Handshaking or Automatic Transmit Flow Control protocols required by the attached serial device. Testing with Extended Hardware Buffering enabled must be performed at the attached device when the physical asynchronous device driver is placed in this mode.

In many Receive and Transmit (half- or full-duplex) scenarios, disabling Input Sensitivity Using DSR has no negative effects. Many communications devices have switches that cause DSR to be constantly ON. Disabling Input Sensitivity Using DSR significantly improves the ability of the serial port hardware to handle receive data without receive hardware overrun errors. Another possible approach is to set Extended Hardware Buffering enabled by using IOCtl ASYNC_SETDCBINFO or the OS/2 MODE command.

In some other Transmit and Receive scenarios, disabling Output Handshaking Using CTS and DSR after a communications link has been established has no adverse effects under normal operating conditions. Again,the achievable performance benefits can be significant. Another possible approach is to set Extended Hardware Buffering enabled by using IOCtl ASYNC_SETDCBINFO.

The potential negative effects of disabling a default control mode of the physical device driver should be thoroughly understood. The potential performance benefits, however, can far outweigh the added complexity of usage and any other potential problems. Such problems can usually be resolved either by reverting to the Automatic Protocol Override mode or by using IOCtl ASYNC_SETDCBINFO to set Extended Hardware Buffering to disabled.

The per-character processing requirements must be addressed when deciding whether to override one of the default protocols of the physical device driver. Possible data integrity problems, such as receive overrun errors, loss of data at the beginning or end of a communications session, or receipt of invalid data on a noisy communications connection can occur. Such problems must be considered before using the potential performance benefits associated with Extended Hardware Buffering.

For ports operating at a given data-transfer rate, the system has less than 20% interrupt-driven device driver overhead when running with Extended Hardware Buffering enabled (both transmit and receive FIFO buffering active), as compared with running those ports on devices where Extended Hardware Buffering is disabled.

Also of equal importance are the operational characteristics of the device driver. By setting Extended Hardware Buffering enabled, the physical device driver can transmit with the full 16-character FIFO buffer active (essentially transmitting 16 characters at a time), and the Receive Data Available interrupts can provide 4, 8, or 14 characters each to the physical device driver receive queue. This is true no matter what device driver protocols are enabled. Examples of scenarios where setting the FIFO Enabled mode of the physical device driver might be acceptable are:
 * If the user does not care if too many characters are transmitted after a modem connection is broken.
 * If the printer or plotter connected to the system does not lose data when it tells the system (with a modem control signal), to stop transmitting, and the system continues to transmit a significant number (up to 16) of characters.
 * If the system is connected to a modem or another system that is normally set up to always keep DSR ON.
 * If the communications protocol with the remote device does not require the system to respond on a character-by-character basis to input data (for example, when the remote device sends data in blocks and provides error retry capability on a block basis rather than a per-character basis).
 * Note:VCOM.SYS does not currently support buffering.