CPGuide - Generic IOCtl Commands

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation

Control Program Programming Guide and Reference

Introduction to the Control Program Control Program Functions Keyboard Functions Mouse Functions Video Functions Data Types Errors Debugging Kernel Debugger Communications Protocol Device I/O Dynamic Linking Error Management Exception Management Extended Attributes File Management File Names File Systems Generic IOCtl Commands Memory Management Message Management National Language Support Pipes Program Execution Control Queues Semaphores Timers Notices Glossary

OS/2 device drivers are used to access the I/O hardware. The IOCtl functions provide a method for an application, or subsystem, to send device-specific control commands to a physical device driver. These IOCtls are subfunctions that are issued through the DosDevIOCtl API function request. The DosDevIOCtl function request can be used only by OS/2 applications; the INT 21h IOCtl request can be used only by DOS applications.

The category and function fields are as follows. Each code is contained in a byte:

Category Code

0xxx xxxx OS/2-defined

1xxx xxxx User-defined

_xxx xxxx Code.

Function Code

0xxx xxxx Return error, if unsupported

1xxx xxxx Ignore, if unsupported

x0xx xxxx Intercepted by the OS/2 operating system

x1xx xxxx Passed to driver

xx0x xxxx Sends data and commands to device

xx1x xxxx Queries data and information from device

___x xxxx Subfunction.

Notice that the send/query data bit is intended only to standardize the function set; it plays no critical role. Some functions can contain both command and query elements. Such commands are defined as sends data.

Generic IOCtl Function Table

The list of categories and functions for the generic IOCtl requests are as follows:

Category	Function	Description
01h		Serial Device Control
	14h	Reserved
	34h	Reserved
	41h	Set Bit Rate
	42h	Set Line Characteristics (stop, parity, data bits)
	43h	Extended Set Bit Rate
	44h	Transmit Byte Immediate
	45h	Set Break OFF
	46h	Set Modem Control Signals
	47h	Behave As If XOFF Received (stop transmit)
	48h	Behave As If XON Received (start transmit)
	49h	Reserved
	4Bh	Set Break ON
	53h	Set Device Control Block (DCB) Parameters
	54h	Set Enhanced Mode Parameters
	61h	Query Current Bit Rate
	62h	Query Line Characteristics
	63h	Extended Query Bit Rate
	64h	Query COM Status
	65h	Query Transmit Data Status
	66h	Query Modem Control Output Signals
	67h	Query Current Modem Input Signals
	68h	Query Number of Characters in Receive Queue
	69h	Query Number of Characters in Transmit Queue
	6Dh	Query COM Error
	72h	Query COM Event Information
	73h	Query Device Control Block (DCB) Parameters
	74h	Query Enhanced Mode Parameters
02h		Reserved
03h		Video Control
	70h	Allocate an LDT Selector
	71h	Deallocate an LDT Selector
	72h	Query Pointer Draw Address
	73h	Initialize Call Vector Table
	74h	ABIOS Pass-Through
	75h	Allocate an LDT Selector with Offset
	76h	Allocate an LDT Selector with Background Validation Options
	7Eh	Allocate Video Buffer
	7Fh	Get Address to ROM Font
04h		Keyboard Control
	50h	Set Code Page
	51h	Set Input Mode (Default ASCII)
	52h	Set Interim Character Flags
	53h	Set Shift State
	54h	Set Typematic Rate and Delay
	55h	Reserved
	56h	Set Session Manager Hot Key
	57h	Set KCB
	58h	Set Code Page Number
	59h	Set Read/Peek Notification
	5Ah	Alter Keyboard LEDs
	5Bh	Reserved
	5Ch	Set NLS and Custom Code Page
	5Dh	Create New Logical Keyboard
	5Eh	Destroy Logical Keyboard
	71h	Query Input Mode
	72h	Query Interim Character Flags
	73h	Query Shift State
	74h	Read Character Data Records
	75h	Peek Character Data Record
	76h	Query Session Manager Hot Key
	77h	Query Keyboard Type
	78h	Query Code Page Number
	79h	Translate Scan Code to ASCII
	7Ah	Query Keyboard Hardware ID
	7Bh	Query Keyboard Code Page Support Information
05h		Parallel Port Control
	42h	Set Frame Control (CPL, LPI)
	43h	Reserved
	44h	Set Infinite Retry
	45h	Reserved
	46h	Initialize Parallel Port
	47h	Reserved
	48h	Activate Font
	49h	Reserved
	4Bh	Reserved
	4Ch	Reserved
	4Dh	Set Print-Job Title
	4Eh	Set Parallel Port Write Time-Out Value
	4Fh	Reserved
	50h	Reserved
	51h	Reserved
	62h	Query Frame Control
	63h	Reserved
	64h	Query Infinite Retry
	65h	Reserved
	66h	Query Parallel Port Status
	67h	Reserved
	68h	Reserved
	69h	Query Active Font
	6Ah	Verify Font
	6Bh	Reserved
	6Ch	Reserved
	6Dh	Reserved
	6Eh	Query Parallel Port Write Time-Out Value
	6Fh	Reserved
	70h	Reserved
	71h	Reserved
06h		Light Pen Control
07h		Mouse Control
	50h	Reserved
	51h	Notification of Display Mode Change
	52h	Reserved
	53h	Reassign Current Mouse Scaling Factors
	54h	Assign New Mouse Event Mask
	55h	Reassign Mouse Threshold Values
	56h	Set Pointer Shape
	57h	Unmark Collision Area
	58h	Mark Collision Area
	59h	Specify/Replace Pointer Screen Position
	5Ah	Set OS/2-Mode Pointer Draw Device Driver Address
	5Bh	Reserved
	5Ch	Set Current Physical Mouse Device Driver Status Flags
	5Dh	Notification of Mode Switch Completion
	60h	Query Number of Mouse Buttons Supported
	61h	Query Mouse Device Motion Sensitivity
	62h	Query Current Physical Mouse Device Driver Status Flags
	63h	Read Mouse Event Queue
	64h	Query Current Event Queue Status
	65h	Query Current Mouse Event Mask
	66h	Query Current Mouse Scaling Factors
	67h	Query Current Pointer Screen Position
	68h	Query Current Pointer Shape
	69h	Query Mouse Threshold Values
	6Ah	Query Physical Mouse Device Driver Level/Version
	6Bh	Query Pointing Device ID
08h		Logical Disk Control
	00h	Lock Drive
	01h	Unlock Drive
	02h	Redetermine Media (end format)
	03h	Set Logical Map
	04h	Begin Format
	20h	Block Removable
	21h	Query Logical Map
	22h	Reserved
	40h	Removable Media Control
	43h	Set Device Parameters
	44h	Write Logical Track
	45h	Format and Verify Track
	5Dh	Diskette Control
	5Eh	Reserved
	5Fh	Reserved
	60h	Query Media Sense
	63h	Query Device Parameters
	64h	Read Logical Track
	65h	Verify Logical Track
	66h	Status
09h		Physical Disk Control
	00h	Lock Physical Drive
	01h	Unlock Physical Drive
	44h	Write Physical Track
	63h	Query Physical Device Parameters
	64h	Read Physical Track
	65h	Verify Physical Track
0Ah		Character Device Monitor Control
	40h	Register Monitor
0Bh		General Device Control
	01h	Flush Input Buffer
	02h	Flush Output Buffer
	41h	System Notifications for Physical Device Drivers
	60h	Query Monitor Support
0Ch		Advanced Power Management
	40h	Send Power Event
	41h	Set Power Event Res
	42h	Reserved
	60h	Query Power Status
	61h	Query Power Event
	62h	Query PowerInfo
0Dh-7Fh		Reserved Category Codes
80h		Screen Control
	00h	Get Current Video Memory Bank
	01h	Set Current Video Memory Bank
	02-07Fh	Reserved
	08h	Return Adapter Video Configuration
	09h	Return Manufacturer-Specific Adapter Data
	0Ah	Update Adapter Video Information
	0Bh	Return Linear Address Mapped to Physical Address
	0Ch-07Fh	Reserved
80h		OEMHLP Controls
	00h	Query OEM Adaptation Information
	01h	Query Machine Information
	02h	Query Display Combination Code
	03h	Return Video Fonts
	04h	Read EISA Configuration Information-Subfunction 00
	04h	Read EISA Function Information-Subfunction 01
	05h	Query ROM BIOS Information
	06h	Query Miscellaneous Video Information
	07h	Query Video Adapter
	08h	Query SVGA Information
	09h	Query Memory Information
	0Ah	Query, Display Mode, Query, and Set (DMQS) Information
	0Bh	Access and Query PCI BIOS Information
80h		Adapter Presence Check (TESTCFG.SYS)
	40h	Get Copy of BIOS/Adapter
	41h	Issue an IN I/O Instruction
	42h	Issue an OUT I/O Instruction
	60h	Get Bus Architecture
	61h	Return all POS IDs
	62h	Return all EISA IDs
80h		Resource Manager Commands
	01h	Get Resource Manager Node Data
	02h	Enumerate Resource Manager Nodes
80h		CD-ROM Drive and Disk Control
	40h	Reset Drive
	44h	Eject Disk
	46h	Lock/Unlock Door
	50h	Seek
	60h	Device Status
	61h	Identify CD-ROM Driver
	63h	Return Sector Size
	70h	Location of Drive Head
	72h	Read Long
	78h	Return Volume Size
	79h	Get UPC
80h		High-Resolution Timer Driver
	00h	Query Version
	01h	Get Resolution
	02h	Set Resolution
	03h	Get Pointer to Clock Counter
	04h	Free Pointer to Clock Counter
	05h	Block Until Time Elapses
81h		CD-ROM Audio Control
	40h	Audio Channel Control
	50h	Play Audio
	51h	Stop Audio
	52h	Resume Audio
	60h	Return Audio-Channel Information
	61h	Return Audio-Disk Information
	62h	Return Audio-Track Information
	63h	Return Audio-Subchannel Q Information
	65h	Return Audio-Status Information
81h		Touch-Device-Dependent Driver Control
	50h	Reserved
	51h	Reserved
	52h	Set Calibration Constants
	53h	Read Data
	54h	Set Data Mode
	55h	Set Click-Lock Parameters
	56h	Set Touch Thresholds
	57h	Set Emulation XY Offset
	58h	Set Data Report Rate
	59h	Set Low-Pass Filter
	5Ah	Write Memory Location
	5Bh	Reserved
	5Ch	Reserved
	5Dh	Reserved
	5Eh	Reserved
	5Fh	Reserved
	60h	Get Calibration Constants
	61h	Get Data Mode
	62h	Get Click Lock Parameters
	63h	Get Touch Thresholds
	64h	Get Emulation XY Offset
	65h	Get Data Report Rate
	66h	Get Low Pass Filter
	67h	Read Memory Location
81h		Touch-Device-Independent Driver Control
	50h	Set Coordinate System
	51h	Reserved
	52h	Set Selection Mechanism
	53h	Set Event Mask
	54h	Set Queue Size
	55h	Set Emulation State
	60h	Set Coordinate System
	61h	Reserved
	62h	Get Selection Mechanism
	63h	Get Event Mask
	64h	Get Queue Size
	65h	Get Emulation State
	66h	Get Read Event Queue

Category 01h ASYNC (RS232-C) Control IOCtl Commands

Whenever an IOCtl command calls for a NULL pointer, it is the responsibility of the application to set one up for the appropriate Parameter or Data Packet pointer before calling the physical device driver. IOCtls can be interpreted differently by future releases if the pointer is not a NULL pointer. If a NULL pointer is called for and it is not received by the device driver, it is considered an invalid Parameter or Data Packet value.

The physical device driver services each communications port (COM1, COM2, and so forth) independently. IOCtls issued to the physical device driver for a given port have no effect on any other communications ports that the physical device driver is servicing. The application cannot assume a given timing relationship between when the IOCtls are executed and when data is received or transmitted by the ASYNC hardware. Data Carrier Detect (DCD) is the same signal as Receiver Line Signal Detect (RLSD).

The following is a summary of the Category 01h IOCtl Commands:

Function	Description	Name
14h	Reserved
34h	Reserved
41h	Set Bit Rate	ASYNC_SETBAUDRATE
42h	Set Line Characteristics (stop, parity, data bits)	ASYNC_SETLINECTRL
43h	Extended Set Bit Rate	ASYNC_EXTSETBAUDRATE
44h	Transmit Byte Immediate	ASYNC_TRANSMITIMM
45h	Set Break OFF	ASYNC_SETBREAKOFF
46h	Set Modem Control Signals	ASYNC_SETMODEMCTRL
47h	Behave as if XOFF Received (stop transmit)	ASYNC_STOPTRANSMIT
48h	Behave as if XON Received (start transmit)	ASYNC_STARTTRANSMIT
49h	Reserved
4Bh	Set Break ON	ASYNC_SETBREAKON
53h	Set Device Control Block (DCB) Parameters	ASYNC_SETDCBINFO
54h	Set Enhanced Mode Parameters	ASYNC_SETENHANCEDMODEPARMS
61h	Query Current Bit Rate	ASYNC_GETBAUDRATE
62h	Query Line Characteristics	ASYNC_GETLINECTRL
63h	Extended Query Bit Rate	ASYNC_EXTGETBAUDRATE
64h	Query COM Status	ASYNC_GETCOMMSTATUS
65h	Query Transmit Data Status	ASYNC_GETLINESTATUS
66h	Query Modem Control Output Signals	ASYNC_GETMODEMOUTPUT
67h	Query Current Modem Input Signals	ASYNC_GETMODEMINPUT
68h	Query Number of Characters in Receive Queue	ASYNC_GETINQUECOUNT
69h	Query Number of Characters in Transmit Queue	ASYNC_GETOUTQUECOUNT
6Dh	Query COM Error	ASYNC_GETCOMMERROR
72h	Query COM Event Information	ASYNC_GETCOMMEVENT
73h	Query Device Control Block (DCB) Parameters	ASYNC_GETDCBINFO
74h	Query Enhanced Mode Parameters	ASYNC_GETENHANCEDMODEPARMS

Asynchronous (RS232-C) Communications Physical 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:

• 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 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.

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:

• 3F8H (must generate a level 4 interrupt)
• 2F8H (must generate a level 3 interrupt)

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:

• 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:

• Data Terminal Ready (DTR)
• Request To Send (RTS)

There are four separate modem control signals whose input values are available to the physical device driver:

• Data Set Ready (DSR)
• Clear To Send (CTS)
• Data Carrier Detect (DCD), also known as Receive Line Signal Detect (RLSD)
• Ring Indicator (RI)

The receive and transmit data lines have the following hardware characteristics:

• 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.

The modem control signal lines have the following hardware characteristics:

• 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 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:

• Query Number of Characters in Receive Queue (ASYNC_GETINQUECOUNT)
• Query Number of Characters in Transmit Queue (ASYNC_GETOUTQUECOUNT)

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.

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 States of the ASYNC Device Driver. 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:

• Controlling or monitoring those modem control signals
• Monitoring the queue status
• Monitoring data moving across the link

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.

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:

• Open and Close processing of DTR and RTS
• Disable/Enable DTR and RTS
• RTS toggling on transmit
• Input handshaking using DTR and RTS

These control modes are described in the section on States of the ASYNC Device Driver, and in the IOCtls description.

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:

• Output handshaking using CTS, DSR, DCD
• Input sensitivity using DSR

These control modes are described in the section on States of the ASYNC Device Driver and in the IOCtls description. Additional information on the state of the input modem control signals is available by using the IOCtl ASYNC_GETCOMMEVENT.

Logical Flow Control (XON/XOFF)

The application can attempt to manually control the flow of data by using the following IOCtls:

• Transmit Immediate (ASYNC_TRANSMITIMM)
• Stop Transmit Behave as if XOFF Received (ASYNC_STOPTRANSMIT)
• Start Transmit Behave as if XON Received (ASYNC_STARTTRANSMIT)

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).

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 States of the ASYNC Device Driver.

Break and Error Processing

The device driver can be commanded to transmit a Break with an IOCtl (See IOCtls 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:

• 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.

See the Set Device Control Block (DCB) Parameters Note on the IOCtl ASYNC_SETDCBINFO.

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:

• 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

Each of the above states are covered as follows:

• 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_SETDCBINFO.

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 Receive Flow Control.
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.
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.

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.

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.

Initial Value

All defined bits are 0

First Level

Open All defined bits are 0

Mode Utility

Not applicable

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.

Initial Value

7 data bits

First Level

Open No effect

Mode Utility

User interface to change the number of data bits

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.

Initial Value

When the physical device driver starts the port during device driver initialization, their values are turned OFF.

First Level

Open The signals are normally turned ON, but there are many conditions that can cause the signals to be affected differently. See IOCtls ASYNC_SETMODEMCTRL and ASYNC_SETDCBINFO for a complete explanation.

Close Considerations

A Close request packet causes DTR and RTS to be turned OFF after the transmit hardware has completely transmitted all the data sent by the physical device driver. After processing this Close request, the port is no longer open from another OPEN without a CLOSE. In addition, at least 10 additional character times must have elapsed (or one second, whichever is less).

Mode Utility

Not applicable for direct control. Indirect effects through altering processing modes of the physical device driver are possible.

DTR Control Mode

The control modes for DTR are:

• Enable
• Disable
• Input Handshaking

The Enable and Disable control modes of DTR affect DTR processing during a First Level Open. When these control modes are set through IOCtl 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.

Initial Value

Enable

First Level

Open No effect

Mode Utility

User interface to change the DTR Control Mode of the physical device driver

Error Replacement Character

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

Initial Value

00h

First Level

Open Reset to 00h

Mode Utility

No effect

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).

Initial Value

Error replacement character processing is disabled

First Level

Open Error replacement character processing is disabled

Mode Utility

No effect

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 Hardware Support for Extended Hardware Buffering.

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:

• Enabled
• Disabled
• Automatic Protocol Override

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.

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:

• 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

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).

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:

• 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.

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.

Initial Value

Automatic Protocol Override mode is on

First Level

Open No effect

Mode Utility

User interface to set the Extended Hardware Buffering mode to ENABLED, DISABLED, or to Automatic Protocol Override

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.

Initial Value

Input Sensitivity using DSR is enabled

First Level

Open No effect

Mode Utility

User interface to enable/disable this mode of the physical device driver

Automatic Override

When Input Sensitivity Using DSR is enabled, the physical device driver responds to the lowering of the DSR line within a single character time. That is, the Extended Hardware Buffering (Receive Trigger Level) is adjusted so the device generates an interrupt for each character received. The full 16-character receive buffer is still available to help avoid any receive hardware overruns. The Transmit FIFO feature is also still enabled so that only one transmit interrupt occurs for every 16 characters transmitted.

Note

: In situations where DSR can naturally drop from O to OFF at the end of a communications session, but is not normally toggled during the session, it is most advantageous to disable Input Sensitivity Using DSR after the communications data transfer has begun. This achieves a significant performance benefit (under the control of Automatic Protocol Override), without the risk of losing valid data upon termination of the session. If, however, the DSR signal is expected to toggle frequently during a communications session, Input Sensitivity Using DSR should not be disabled, or potential data loss can result.

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.

Initial Value

Null stripping is disabled

First Level

Open Null stripping is disabled

Mode Utility

No effect

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.

Initial Value Output handshaking using CTS and DSR is enabled. Output handshaking using DCD is disabled.

First Level

Open No effect.

Mode Utility

User interface to enable/disable this mode of the physical device driver for CTS and DSR (independently). Mode always disables this mode of operation of the physical device driver for DCD.

Automatic Override

When Output Handshaking using DSR, CTS, or DCD is enabled, the physical device driver responds to the dropping modem line within a single character time. That is, Automatic Protocol Override controls the Extended Hardware Buffering capability so that only one character at a time is given to the transmit hardware (Transmit Buffer Load Count is set to 1). The Receive Trigger Level is unaffected.

Parity

Determines whether a parity bit exists and, if appropriate, what algorithm determines its value. See IOCtls ASYNC_SETLINECTRL and ASYNC_GETLINECTRL.

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:

• Enable
• Disable
• Input Handshaking
• Toggling on Transmit

The Enable and Disable control modes affect RTS processing during a First Level Open. When these control modes are set using IOCtl 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.

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 ASYNC_TRANSMITIMM), 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.

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 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.

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:

• 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 must get an INIT request packet for the device name.
• The ASYNC LID corresponding to the device name must be available.

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:

• 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.

Request	Description
INIT	Initialize the device
Open	Open the device
Close	Close the device
Read	Read from the device (Normal, Non-Destructive No-Wait)
Write	Write to the device
Status	Input or output status
Flush	Flush or terminate all pending requests

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 States of the ASYNC Device Driver. 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 States of the ASYNC Device Driver. 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 States of the ASYNC Device Driver.

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:

Function	Category 01h IOCtls
	Line Characteristics
41h	Set Bit Rate
42h	Set Line Characteristics (stop, parity, data bits)
43h	Extended Set Bit Rate
46h	Set Modem Control Signals
61h	Query Current Bit Rate
62h	Query Line Characteristics
63h	Extended Query Bit Rate
66h	Query Modem Control Output Signals
67h	Query Current Modem Input Signals
	Manual XON/XOFF (Flow Control) Processing
44h	Transmit Byte Immediate
47h	Behave as if XOFF Received (stop transmit)
48h	Behave as if XON Received (start transmit)
	Break Processing
45h	Set Break OFF
4Bh	Set Break ON
	Device Driver I/O Queue Management
68h	Query Number of Characters in Receive Queue
69h	Query Number of Characters in Transmit Queue
	Polled Events
64h	Query COM Status
65h	Query Transmit Data Status
6Dh	Query COM Error
72h	Query COM Event Information
	Enhanced Parameters
54h	Set Enhanced Mode Parameters
74h	Query Enhanced Mode Parameters
	Device Control Block (DCB) Parameter Access
53h	Set Device Control Block Parameters
73h	Query Device Control Block Parameters

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)

See Generic IOCtl Commands for more information about Category 01h IOCtls.

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 (See IOCtl 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.

Category 03h Video Control IOCtl Commands

The following is a summary of the Category 03h Video Control IOCtl Commands:

Function	Description	Name
70h	Allocate an LDT Selector	SCR_ALLOCLDT (70h)
71h	Deallocate an LDT Selector	SCR_DEALLOCLDT (71h)
72h	Query Pointer Draw Address	PTR_GETPTRDRAWADDRESS (72h)
73h	Initialize Call Vector Table	VID_INITCALLVECTOR (73h)
74h	ABIOS Pass-Through	SCR_ABIOSPASSTHRU (74h)
75h	Allocate an LDT Selector with Offset	SCR_ALLOCLDTOFF (75h)
76h	Allocate an LDT Selector with Background Validation Options	SCR_ALLOCLDTBGVAL (76h)
7Eh	Allocate Video Buffer	SCR_ALLOCVIDEOBUFFER (7Eh)
7Fh	Get Address to ROM Font	SCR_GETROMFONTADDR (7Fh)

Category 04h Keyboard Control IOCtl Commands

The following is a summary of the Category 04h IOCtl Commands:

Function	Description	Name
50h	Set Code Page	KBD_SETTRANSTABLE
51h	Set Input Mode (Default ASCII)	KBD_SETINPUTMODE
52h	Set Interim Character Flags	KBD_SETINTERIMFLAG
53h	Set Shift State	KBD_SETSHIFTSTATE
54h	Set Typematic Rate and Delay	KBD_SETTYPAMATICRATE
55h	Reserved
56h	Set Session Manager Hot Key	KBD_SETSESMGRHOTKEY
57h	Set KCB	KBD_SETKCB
58h	Set Code Page Number	KBD_SETCP
59h	Set Read/Peek Notification	KBD_SETREADNOTIFICATION
5Ah	Alter Keyboard LEDs	KBD_ALTERKBDLED
5Bh	Reserved
5Ch	Set NLS and Custom Code Page	KBD_SETNLS
5Dh	Create a New Logical Keyboard	KBD_CREATE
5Eh	Destroy a Logical Keyboard	KBD_DESTROY
71h	Query Input Mode	KBD_GETINPUTMODE
72h	Query Interim Character Flags	KBD_GETINTERIMFLAG
73h	Query Shift State	KBD_GETSHIFTSTATE
74h	Read Character Data Records	KBD_READCHAR
75h	Peek Character Data Record	KBD_PEEKCHAR
76h	Query Session Manager Hot Key	KBD_GETSESMGRHOTKEY
77h	Query Keyboard Type	KBD_GETKEYBDTYPE
78h	Query Code Page Number	KBD_GETCODEPAGEID
79h	Translate Scan Code to ASCII	KBD_XLATESCAN
7Ah	Query Keyboard Hardware ID	KBD_QUERYKBDHARDWAREID
7Bh	Query Keyboard Code Page Support Information	KBD_QUERYKBDCODEPAGESUPPORT

Category 05h Parallel Port Control IOCtl Commands

The following is a summary of Category 05h IOCtl Commands:

Function	Description	Name
42h	Set Frame Control (CPL, LPI)	PRT_SETFRAMECTL
43h	Reserved
44h	Set Infinite Retry	PRT_SETINFINITERETRY
45h	Reserved
46h	Initialize Parallel Port	PRT_INITPRINTER
47h	Reserved
48h	Activate Font	PRT_ACTIVATEFONT
49h	Reserved
4Bh
4Ch
4Dh	Set Print-Job Title	PRT_SETPRINTJOBTITLE
4Eh	Set Parallel Port Write Timeout Value	PRT_SETIRQTIMEOUT
4Fh	Reserved
50h
51h
62h	Query Frame Control	PRT_GETFRAMECTL
63h	Reserved
64h	Query Infinite Retry	PRT_GETINFINITERETRY
65h	Reserved
66h	Query Parallel Port Status	PRT_GETPRINTERSTATUS
67h	Reserved
68h
69h	Query Active Font	PRT_QUERYACTIVEFONT
6Ah	Verify Font	PRT_VERIFYFONT
6Bh	Reserved
6Ch
6Dh
6Eh	Query Parallel Port Write Timeout Value	PRT_QUERYIRQTIMEOUT
6Fh	Reserved
70h
71h

Category 07h Mouse Control IOCtl Commands

The following is a summary of Category 07h IOCtl Commands:

Function	Description	Name
50h	Reserved
51h	Notification of Display Mode Change	MOU_UPDATEDISPLAYMODE
52h	Reserved
53h	Reassign Current Mouse Scaling Factors	MOU_SETSCALEFACTORS
54h	Assign New Mouse Event Mask	MOU_SETEVENTMASK
55h	Reassign Mouse Threshold Values	MOU_REASSIGNTHRESHOLDVALUES
56h	Set Pointer Shape	MOU_SETPTRSHAPE
57h	Unmark Collision Area	MOU_UNMARKCOLLISIONAREA
58h	Mark Collision Area	MOU_MARKCOLLISIONAREA
59h	Specify/Replace Pointer Screen Position	MOU_SETPTRPOS
5Ah	Set OS/2 Mode Pointer Draw Device Driver Address	MOU_SETPROTDRAWADDRESS
5Bh	Reserved
5Ch	Set Current Physical Mouse Device Driver Status Flags	MOU_SETMOUSTATUS
5Dh	Notification of Mode Switch Completion	MOU_DISPLAYMODECHANGE
60h	Query Number of Mouse Buttons Supported	MOU_GETBUTTONCOUNT
61h	Query Mouse Device Motion Sensitivity	MOU_GETMICKEYCOUNT
62h	Query Current Physical Mouse Device Driver Status Flags	MOU_GETMOUSTATUS
63h	Read Mouse Event Queue	MOU_READEVENTQUE
64h	Query Current Event Queue Status	MOU_GETQUESTATUS
65h	Query Current Mouse Event Mask	MOU_GETEVENTMASK
66h	Query Current Mouse Scaling Factors	MOU_GETSCALEFACTORS
67h	Query Current Pointer Screen Position	MOU_GETPTRPOS
68h	Query Current Pointer Shape	MOU_GETPTRSHAPE
69h	Query Mouse Threshold Values	MOU_QUERYTHRESHOLDVALUES
6Ah	Query Physical Mouse Device Driver Level/Version Number	MOU_VER
6Bh	Query Pointing Device ID	MOU_QUERYPOINTERID

Category 08h Logical Disk Control IOCtl Commands

The following is a summary of Category 08h IOCtl Commands:

Function	Description	Name
00h	Lock Drive	DSK_LOCKDRIVE
01h	Unlock Drive	DSK_UNLOCKDRIVE
02h	Redetermine Media	DSK_REDETERMINEMEDIA
03h	Set Logical Map	DSK_SETLOGICALMAP
04h	Begin Format	DSK_BEGINFORMAT
20h	Block Removable	DSK_BLOCKREMOVABLE
21h	Query Logical Map	DSK_GETLOGICALMAP
22h	Reserved
40h	Removable Media Control	DSK_UNLOCKEJECTMEDIA
43h	Set Device Parameters	DSK_SETDEVICEPARAMS
44h	Write Logical Track	DSK_WRITETRACK
45h	Format and Verify Track	DSK_FORMATVERIFY
5Dh	Diskette Control	DSK_DISKETTECONTROL
5Eh	Reserved
5Fh	Reserved
60h	Query Media Sense	DSK_QUERYMEDIASENSE
63h	Query Device Parameters	DSK_GETDEVICEPARAMS
64h	Read Logical Track	DSK_READTRACK
65h	Verify Logical Track	DSK_VERIFYTRACK
66h	Status	DSK_GETLOCKSTATUS

Category 09h Physical Disk Control IOCtl Commands

Category 09h is used to access physical partitionable hard disks. The handle used for Category 09h command is returned by the DosPhysicalDisk (Function 2) API function. (See the OS/2 Control Program Programming Reference for more information). This handle is used to tell the system which physical disk is accessed by the IOCtl command.

The Physical Disk Control commands relate to the entire partitionable hard disk. Direct track and sector I/O start at the beginning of the physical drive. PDSK_GETPHYSDEVICEPARAMS, describes the entire physical device.

The following is a summary of Category 09h IOCtl Commands:

Function	Description	Name
00h	Lock Physical Drive	PDSK_LOCKPHYSDRIVE
01h	Unlock Physical Drive	PDSK_UNLOCKPHYSDRIVE
44h	Write Physical Track	PDSK_WRITEPHYSTRACK
63h	Query Physical Device Parameters	PDSK_GETPHYSDEVICEPARAMS
64h	Read Physical Track	PDSK_READPHYSTRACK
65h	Verify Physical Track	PDSK_VERIFYPHYSTRACK

Category 0Ah Character Device Monitor IOCtl Command

The following is the Category 0Ah IOCtl Command:

Function	Description
40h	Register Monitor	MON_REGISTERMONITOR

Category 0Bh General Device Control IOCtl Commands

The following is a summary of Category 0Bh IOCtl Commands:

Function	Description
01h	Flush Input Buffer	DEV_FLUSHINPUT
02h	Flush Output Buffer	DEV_FLUSHOUTPUT
41h	System Notifications for Physical Device Drivers	DEV_SYSTEMNOTIFYPDD
60h	Query Monitor Support	DEV_QUERYMONSUPPORT

Category 0Ch Advanced Power Management

Function	Description
40h	Send Power Event	POWER_SENDPOWEREVENT
41h	Set Power Event Resource	POWER_SETPOWEREVENTRES
42h - 44h	Reserved
45h	OEM APM Function
60h	Query Power Status	POWER_GETPOWERSTATUS
61h	Query Power Event	POWER_GETPOWEREVENT
62h	Query Power Information	POWER_GETPOWERINFO
63h	Query Power State

Category 80h Screen Control IOCtl Commands

The following video IOCtls are defined and supported by the SCREENDD$ device driver, by way of the DosDevIOCtl call. The IOCtl category code is 80h (defined as SCREENDD_CATEGORY).

The function codes within the SCREENDD_CATEGORY are:

Function	Description
00h	Get Current Video Memory Bank	SCREENDD_GETCURRENTBANK
01h	Set Current Video Memory Bank	SCREENDD_SETCURRENTBANK
02h-07h	Reserved
08h	Return Adapter Video Configuration	SCREENDD_SVGA_ID
09h	Return Manufacturer-Specific Adapter Data	SCREENDD_SVGA_OEM
0Ah	Update Adapter Video Memory Information	SCREENDD_UPDATEMEMORY
0Bh	Return Linear Address Mapped to Physical Address	SCREENDD_GETLINEARACCESS
0Ch-7Fh	Reserved

An example of the DosDevIOCtl calling convention for the Screen IOCtls follows:

int PASCAL near videoIoctl(VOID *data,VOID *parm,USHORT function)
{
  unsigned hScreenDD;                  /* handle of SCREENDD$ dev driver */
  unsigned OpenAction;                 /* action taken to open device    */
  unsigned rc;                         /* function return code           */


  if (!(rc = DosOpen(SCREENDD_NAME, (PHFILE)&hScreenDD, (PUSHORT)&OpenAction,
     NO_SIZE, NO_ATTRIBUTES, OPEN_IF_EXISTS, NO_INHERIT+DENY_NONE+READ_WRITE,
     RESERVED_LONG)))
  {
    rc = DosDevIOCtl(data,
                     parm,
                     function,
                     SCREENDD_CATEGORY,
                     (HFILE)hScreenDD);
    DosClose(hScreenDD);
  }
  return (rc);

Category 80h OEMHLP IOCtls

The OEMHLP interface was originally designed to allow Original Equipment Manufacturers (OEMs) to modify and adapt the OS/2 operating system to run on their hardware. In the past, IBM supported the OS/2 operating system on IBM hardware only. Therefore, OEMs had to build modified versions of the OS/2 operating system. The OEMHLP interface facilitated this process.

IBM currently tests the OS/2 operating system on a wide variety of OEM hardware. It is no longer necessary for OEMs to adapt the OS/2 operating system to their machines. Now the OEMHLP interface can be used to obtain real-mode information. This information can be passed to applications and device drivers running in protect mode. Applications and physical device drivers running in protect mode cannot access BIOS through the INT interface. The OEMHLP interface allows access to BIOS information and functions that are essential to these programs.

For example, you might want to issue INT 15h calls from your device driver initialization code to determine if an Extended Industry Standard Architecture (EISA) adapter is present. The following examples show the methods to determine if a specific EISA or Micro Channel adapter is present.

Using the Query Adapter ID to Verify EISA Adapter

The following example uses the OEMHLP IOCtl interface to verify the EISA card ID:

USHORT FindMyEISACard(void)
{
  HFILE filehandle;
  USHORT action;

  EISAFunctionInfo.efi_SubFunc = OEM_GET_SLOT_INFO; /* EISA Get Slot Info */
  EISAFunctionInfo.efi_Slot    = 0;                 /* Slot 0             */

  rc = DosOpen("OEMHLP$",
               &filehandle,
               &action,
               0L,
               0,
               1,
               0x40,
               0L);
  if (rc == 0)
    {
    for(index=1;index<CFG_MAX_EISA_SLOTS;index++)   /* For each slot      */
      {
      EISAFunctionInfo.efi_Slot    = (UCHAR) index; /* Slot Number        */
      EISASlotInfo.esi_CardID  = 0;                 /* Reset Card ID value*/
      rc = DosDevIOCtl((PVOID)&EISASlotInfo,        /* Data Packet */
                       (PVOID)&EISAFunctionInfo,    /* Parm Packet */
                       (USHORT)OEMHLP_QUERYEISACONFIG,
                       (USHORT)OEMHLP_CATEGORY,
                       (HFILE)filehandle);
      /* If IOCtl successful and slot has adapter, then store away
         the adapter ID, otherwise mark as empty with a zero.
       */
      if((rc==0)&&(EISASlotInfo.esi_Error==0))
        {
        if (EISASlotInfo.esi_CardID == MYCARDID)
           DosClose(filehandle);        /* Close handle to OEMHLP$ */
           return(FOUND);
        }
      }
      DosClose(filehandle);             /* Close handle to OEMHLP$ *    /
    }
   return(NOTFOUND);
}

Using the DevHlp_ABIOSCall to Verify Micro Channel Adapter

The following example uses the DevHlp_ABIOSCall to verify the Micro Channel POS ID:

USHORT FindMyMicroChannelCard(void)
{
  USHORT i,rc;             /* Index and return code    */
  USHORT LID;              /* Logical ID               */

  if (GetLIDEntry(POS,0,1,&LID))
     return(NOTFOUND);

  /* Get length of RB to use for reading POS data. */

  POSLenRB.rb.RBLen = sizeof(POSLENRB);
  POSLenRB.rb.Func  = 0x01;
  POSLenRB.rb.LID   = LID;
  POSLenRB.rb.Unit  = 0;
  POSLenRB.rb.Resv1 = 0;
  POSLenRB.rb.Resv2 = 0;
  POSLenRB.Rsv1     = 0;
  POSLenRB.Rsv2     = 0;
  POSLenRB.Rsv3     = 0;
  rc = ABIOSCall( LID, &POSLenRB, 0);

  /*Is my request block big enough? */

  if ((rc==0) && (sizeof(POSRB) >= POSLenRB.RBLen))
     {
       RB.rb.RBLen = POSLenRB.RBLen;       /* request block length        */
       RB.rb.Func  = 0x0b;                 /* read stored POS data to mem */
       RB.rb.LID   = LID;                  /* Logical ID                  */
       RB.rb.Unit  = 0;
       RB.DataBuf  = (ULONG)(FARPOINTER)&POSData;

       for(i=0;i<=CFG_MAX_POS_SLOTS;i++)   /* For each slot, get POS ID   */
          {
           RB.Slot = (UCHAR)i;
           rc = ABIOSCall(LID,&RB,0);
           if((rc==0)&&(RB.rb.RetCode==0))
             if (RB.AdapterID == MYCARD)
                {
                  FreeLIDEntry(LID);
                  return(FOUND);
                }
          }
     }

  FreeLIDEntry(LID);             /* Release LID Entry */
  return(NOTFOUND);
}

OEMHLP IOCtls Summary

The following is a summary of Category 80h OEMHLP IOCtl Commands:

Function	Description	Name
00h	Query OEM Adaptation Information	OEMHLP_GETOEMADAPTIONINFO
01h	Query Machine Information	OEMHLP_GETMACHINEINFO
02h	Query Display Combination Code	OEMHLP_GETDISPLAYCOMBCODE
03h	Return Video Fonts	OEMHLP_GETVIDEOFONTS
04h	Read EISA Slot Configuration Information -	OEMHLP_READEISACONFIGINFO
(04h) - 00	Subfunction 00
04h	Read EISA Function Configuration Information -	OEMHLP_READEISACONFIGINFO
(04h) - 01	Subfunction 01
05h	Query ROM BIOS Information	OEMHLP_GETROMBIOSINFO
06h	Query Miscellaneous Video Information	OEMHLP_GETMISCVIDEOINFO
07h	Query Video Adapter	OEMHLP_GETVIDEOADAPTER
08h	Query SVGA Information	OEMHLP_GETSVGAINFO
09h	Query Memory Information	OEMHLP_GETMEMINFO
0Ah	Query Display Mode, Query and Set (DMQS) Information	OEMHLP_GETDMQSINFO
0Bh	Access PCI BIOS Information	OEMHLP_PCI
0Bh	Query PCI BIOS Information - Subfunction 00h	OEMHLP_PCI (0Bh) - 00h
0Bh	Find PCI Device - Subfunction 01h	OEMHLP_PCI (0Bh) - 01h
0Bh	Find PCI Class Code - Subfunction 02h	OEMHLP_PCI (0Bh) - 02h
0Bh	Read PCI Configuration Space - Subfunction 03h	OEMHLP_PCI (0Bh) - 03h
0Bh	Write PCI Configuration Space - Subfunction 04h	OEMHLP_PCI (0Bh) - 04h

Category 80h Adapter Presence-Check Services (TESTCFG.SYS)

The TESTCFG device driver provides services for automatic detection of Original Equipment Manufacturer (OEM) hardware interfaces. Functions provided by this driver are accessed entirely by opening the device name TESTCFG$ and using the following Category 80h IOCtls.

Function	Description
40H	Get Copy of BIOS/Adapter Memory	TESTCFG_SYS_GETBIOSADAPTER
41H	Issue an "IN" I/O Instruction	TESTCFG_SYS_ISSUEINIOINSTR
42H	Issue an "OUT" I/O Instruction	TESTCFG_SYS_ISSUEOUTIOINSTR
60H	Get Bus Architecture Function	TESTCFG_SYS_GETBUSARCH
61H	Return All POS IDs	TESTCFG_SYS_GETALLPOSIDS
62H	Return All EISA IDs	TESTCFG_SYS_GETALLEISAIDS

Category 80h Resource Manager IOCtl Commands

RESOURCE.SYS provides two IOCtls that allow a ring 3 application to obtain a "snapshot" of the Resource Management data structures. Obtaining a snapshot of the Resource Management data structures consists of the following two steps:

1. A data structure representing a depth-first traversal of the Resource Manager node structure is obtained.
2. For each node traversed, the following information is provided:

   A Resource Manager handle to access the node.

   The depth of the node in the tree structure.

3. A copy of each Resource Manager node can be obtained by supplying the node handle returned in Step 1.

Function	Description
01h	Get Resource Manager Node Data
02h	Enumerate Resource Manager Nodes

Category 80h CD-ROM Drive and Disc IOCtl Commands

The OS/2 CD-ROM Device Manager provides an interface through generic IOCtls.

The CD-ROM device driver returns error values in the range of hex FF00 through FF14. DOS DevIOCtl return codes are described in the OS/2 Programming Reference manuals.

Function	Description
40h	Reset Drive	CDROMDISK_RESETDRIVE
44h	Eject Disc	CDROMDISK_EJECTDISK
45h	Close Tray	CDROMDISK_CLOSETRAY
46h	Lock/Unlock Door	CDROMDISK_LOCKUNLOCKDOOR
50h	Seek	CDROMDISK_SEEK
60h	Return Device Status	CDROMDISK_DEVICESTATUS
61h	Identify CD-ROM Driver	CDROMDISK_GETDRIVER
63h	Return Sector Size	CDROMDISK_GETSECTORSIZE
70h	Report Location of Drive Head	CDROMDISK_GETHEADLOC
72h	Read Long	CDROMDISK_READLONG
78h	Return Volume Size	CDROMDISK_GETVOLUMESIZE
79h	Get UPC	CDROMDISK_GETUPC

Category 80h High-Resolution Timer IOCtl Commands

The following IOCtls are defined and supported by the TIMER0$ device driver by way of the DosDevIOCtl call. The IOCtl category code is 80h (defined as HRT_IOCTL_CATEGORY).

The function codes within the HRT_IOCTL_CATEGORY are:

Function	Description
00h	Get Version	HRT_QUERY_VERSION
01h	Get Resolution	HRT_GET_RESOLUTION
02h	Set Resolution	HRT_SET_RESOLUTION
03h	Get Pointer to Clock Timer	HRT_GET_POINTER
04h	Free Pointer to Clock Timer	HRT_FREE_POINTER
05h	Block Until Time Elapses	HRT_BLOCKUNTIL
06h-7Fh	Reserved

An example of the DosDevIOCtl calling convention for reading the current time follows:

   #include "tmr0_ioc.h"

   APIRET rc           = NO_ERROR;
   HFILE  hfile        = NULLHANDLE;
   ULONG  ulAction     = 0L;

   ULONG  ulResolution = 1;
   ULONG  ulSize1      = sizeof(ulResolution);

   ULONG  * _Seg16 pulTimer16;             // defines a 16:16 pointer
   ULONG  ulSize2      = sizeof(pulTimer16);
   ULONG  *pulTimer;

   rc=DosOpen( "TIMER0$ ",
               &hfile,
               &ulAction,
               0,0,
               OPEN_ACTION_OPEN_IF_EXISTS,
               OPEN_FLAGS_FAIL_ON_ERROR | OPEN_SHARE_DENYNONE |
               OPEN_ACCESS_READWRITE,
               NULL);
   if (rc) {
      printf("Couldn't open TIMER0$.\n");
      return;
   }

   printf("TIMER0$ opened. File Handle is %lu\n",hfile);

   rc=DosDevIOCtl( hfile,
                   HRT_IOCTL_CATEGORY,
                   HRT_SET_RESOLUTION,
                   &ulResolution,
                   ulSize1,
                   &ulSize1,
                   NULL,
                   0,
                   NULL);
   if (rc) {
      printf("Couldn't set resolution.\n");
      DosClose(hfile);
      return;
   }

   rc=DosDevIOCtl( hfile,
                   HRT_IOCTL_CATEGORY,
                   HRT_GET_POINTER,
                   NULL,
                   0,
                   NULL,
                   &pulTimer16,
                   ulSize2,
                   &ulSize2);
   if (rc) {
      printf("Couldn't get pointer.\n");
      DosClose(hfile);
      return;
   }

   pulTimer = pulTimer16;    // converts a 16:16 pointer to a 0:32 pointer
   if (!pulTimer) {
      printf("NULL pointer.\n");
      DosClose(hfile);
      return;
   }

   // At this point, pulTimer is now a pointer to the timer 0 counter variable.

   rc=DosClose(hfile);

The DosOpen of TIMER0$ registers the application as a client. At this point, the high-resolution timer (HRT) is taking interrupts, so only open the driver when timer services are needed. The pointer is valid for the life of the process, and each call to HRT_GET_POINTER allocates another selector, so this call should only be made once.

While the HRT is taking interrupts, DOS sessions (VDMs) will not receive INT 8 or INT 1Ch calls. The reason for this is that OS/2 only allows one device driver to receive interrupts on a given IRQ, and VTIMER.SYS (the VDD that provides INT 8 and INT 1Ch services to VDM's) expects CLOCK0x.SYS to deliver IRQ 0 interrupts. When the HRT is active, it receives the IRQ 0 interrupts instead of CLOCK0x.SYS, and thus VTIMER.SYS never gets them either.

Note: Performance tools, such as C Set's DDE4XTRA.SYS and VisualAge's CPPOPA3.SYS, are incompatible with this driver. Performance analysis tools cannot be run while the high-resolution timer is active, and vice versa.

The following code segment illustrates how to block a time-critical thread until a certain time has eleapsed. Return code checking has been omitted for brevity. A time-critical thread should be used for this function.

   ULONG ulDelay = 1;               // Number of milliseconds to wait
   ULONG ulSize2 = sizeof(ulDelay);

   DosOpen("TIMER0$ ", &hfile,
           &ulAction,0,0,ulOpenFlag,ulOpenMode,NULL);

   DosSetPriority(0,PRTYC_TIMECRITICAL,0,0);

   DosDevIOCtl( hfile,
                HRT_IOCTL_CATEGORY,
                HRT_BLOCKUNTIL,
                &ulDelay,
                ulSize2,
                &ulSize2,
                NULL,
                0,
                NULL);

Category 81h CD-ROM Audio IOCtl Commands

The OS/2 CD-ROM Device Manager provides an interface through generic IOCtls.

The CD-ROM device driver returns error values in the range of hex FF00 through FF14. DOSDevIOCtl return codes are described in the OS/2 Programming Reference manuals.

Function	Description
40h	Set Audio Channel Control	CDROMAUDIO_SETCHANNELCTRL
50h	Play Audio	CDROMAUDIO_PLAYAUDIO
51h	Stop Audio	CDROMAUDIO_STOPAUDIO
52h	Resume Audio	CDROMAUDIO_RESUMEAUDIO
60h	Return Audio-Channel Information	CDROMAUDIO_GETCHANNEL
61h	Return Audio-Disk Information	CDROMAUDIO_GETAUDIODISK
62h	Return Audio-Track Information	CDROMAUDIO_GETAUDIOTRACK
63h	Return Audio-Subchannel Q Information	CDROMAUDIO_GETSUBCHANNELQ
65h	Return Audio-Status Information	CDROMAUDIO_GETAUDIOSTATUS

Category 81h Touch Device-Dependent Driver

All Touch device driver IOCtl commands share Category 81h commands, which are distinguished by the device name used in the device Open (PDITOU$ for the device-dependent driver, TOUCH$ for the device-independent driver).

Device-Dependent Device Driver Command Summary

The following table describes the Category 81h Touch Device-Dependent Driver IOCtl commands:

Function	Description
50h	Reserved.
51h	Reserved.
52h	Set Calibration Constants	TOUCH_DEVDEP_SETCALIBCONST
53h	Read Data	TOUCH_DEVDEP_READDATA
54h	Set Data Mode	TOUCH_DEVDEP_SETDATAMODE
55h	Set Click-Lock Parameters	TOUCH_DEVDEP_SETCLICKLOCK
56h	Set Touch Thresholds	TOUCH_DEVDEP_SETTOUCHTHRESHOLD
57h	Set Emulation XY Offset	TOUCH_DEVDEP_SETEMULXY
58h	Set Data Report Rate	TOUCH_DEVDEP_SETDATAREPORTRATE
59h	Set Low Pass Filter	TOUCH_DEVDEP_SETLOWPASSFILTER
5Ah	Write Memory Location	TOUCH_DEVDEP_WRITEMEMLOC
5Bh	Reserved.
5Ch	Reserved.
5Dh	Reserved.
5Eh	Reserved.
5Fh	Reserved.
60h	Get Calibration Constants	TOUCH_DEVDEP_GETCALIBCONST
61h	Get Data Mode	TOUCH_DEVDEP_GETDATAMODE
62h	Get Click-Lock Parameters	TOUCH_DEVDEP_GETCLICKLOCK
63h	Get Touch Thresholds	TOUCH_DEVDEP_GETTOUCHTHRESHOLD
64h	Get Emulation XY Offset	TOUCH_DEVDEP_GETEMULXY
65h	Get Data Report Rate	TOUCH_DEVDEP_GETDATAREPORTRATE
66h	Get Low Pass Filter	TOUCH_DEVDEP_GETLOWPASSFILTER
67h	Read Memory Location	TOUCH_DEVDEP_READMEMLOC

Category 81h Touch Device-Independent Driver

All Touch device driver IOCtl commands share Category 81h commands, which are distinguished by the device name used in the device Open (PDITOU$ for the device-dependent driver, TOUCH$ for the device-independent driver).

Device-Independent Device Driver Command Summary

The following lists and describes the Category 81h Touch Device-Independent Driver:

Function	Description
50h	Set Coordinate System	TOUCH_DEVINDEP_SETCOORDSYS
51h	Reserved
52h	Set Selection Mechanism	TOUCH_DEVINDEP_SETSELECTMECH
53h	Set Event Mask	TOUCH_DEVINDEP_SETEVENTMASK
54h	Set Queue Size	TOUCH_DEVINDEP_SETQUEUESIZE
55h	Set Emulation State	TOUCH_DEVINDEP_SETEMULSTATE
60h	Get Coordinate System	TOUCH_DEVINDEP_GETCOORDSYS
61h	Reserved
62h	Get Selection Mechanism	TOUCH_DEVINDEP_GETSELECTMECH
63h	Get Event Mask	TOUCH_DEVINDEP_GETEVENTMASK
64h	Get Queue Size	TOUCH_DEVINDEP_GETQUEUESIZE
65h	Get Emulation State	TOUCH_DEVINDEP_GETEMULSTATE
66h	Get Read Event Queue	TOUCH_DEVINDEP_GETREADEVENTQUEUE