6100 BSC Programming Manual

Writing Applications that Use 6100 BSC
There may be a reason for multiple OPENs, despite the rule
against concurrent requests. For example, you might want to use
one OPEN for reading and writing, and another to fetch and
present statistics. This use of OPENs achieves not concurrency,
but a separation of function: an AWAITIO call with a given file
number completes a specific class of requests. Normally,
multiple OPENs are issued by the same process.
-----------------------------------------------------------------
| |
| May not be issued May be issued at |
| concurrently any time |
| |
| SET CONFIGURATION FETCH CONFIGURATION |
| WRITE DATA FETCH STATISTICS |
| READ DATA |
| WRITEREAD DATA |
| CONTROL *ABORT |
| SETMODE **HALT READ |
| |
| |
| *This request supersedes an active request from the |
| first column, for instance a WRITE, even if that |
| request was issued under another OPEN. |
| |
| **This request can also be issued while another |
| request is active; it cancels a READ request that |
| meets certain conditions (described later). |
| |
-----------------------------------------------------------------
Figure 3-1. Request Queuing
If an application uses multiple OPENs, it may issue separate
AWAITIO calls to complete each set of requests, or it may
issue one AWAITIO call with a -1 instead of the file number.
If a request completes with a non-zero condition code, the
FILEINFO call should use the file number returned by AWAITIO.
If an application makes concurrent file system requests
and wants to allow those requests to complete in any order,
it makes a SETMODE 30 call after the OPEN. Then if, for
instance, it issues a FETCH STATISTICS request while a
READ request is pending, the FETCH STATISTICS request can
complete before the READ does.
If multiple processes use the same line, the application must
have a protocol to ensure orderly operation. An alternative
is to have one process act as funnel for requests from other
processes.
3-3