CP6100 I/O Process Programming Manual

Using CP6100: Programming
An application normally issues requests in the following order
for each line it uses:
1. OPEN to gain access to the line, to determine whether access
is exclusive or shared, to specify nowait access and the
number of concurrent requests allowed. (Remember to count
the READ if you're using a protocol that supports it.) If a
process will open the line more than once without first
closing it, it must ask for shared access.
2. SETMODE for requests to complete in any order. If you're
using a protocol that supports READ, this call lets the READ
request complete out of order. If the application opens
the line more than once and devotes an open to the READ
request, then the SETMODE call is unnecessary.
3. READ, if the protocol supports it, to receive unsolicited
error and status messages.
4. WRITEREAD and AWAITIO to place requests and complete them.
5. CLOSE when the application no longer needs access to the
line.
This book describes the file system calls only in relation to
CP6100. This section discusses the calls in general; later
sections provide information about specific protocols. This
book does not give you all the guidance you need to write a
successful program. For a thorough discussion of the file system
calls, consult the GUARDIAN Operating System Programmer's Guide |
for the NonStop System. |
Error Handling and Reporting
Handling errors is one of the inevitable tasks of application
programming. Equipment fails, line quality slackens or the line
can't sustain the desired throughput; people make mistakes in
device configuration or submit unreasonable input to programs
(for example, someone presses the reset button on a terminal
accidentally); someone takes a device off-line or changes its
address without telling everyone who needs to know.
The next few pages show how CP6100, the protocols, and other
software in the 6100 subsystem reduce the burden of error
handling for your application. They also describe the ways
errors are reported to the application, and how programs may
react to different kinds of errors.
October 1985
2-7