This table lists all of the opcodes and describes the interpretation of the flags parameter for each. Note that in several cases, such as with the read, write and check operations, the value of flags relates to a number of data bytes, rather than to bit values as in the Flags1 table..
Opcode |
Interpretation of Flags Parameter |
|---|---|
TCPOP_ACCEPT |
TCPXFLG_BLOCK sets blocking mode, which means that read and write calls wait until they can be completed or the timer expires; in non-blocking mode, if timer=0 and the read/write operation cannot be immediately completed, an error status is returned. |
TCPOP_WRITE |
Specifies the number of bytes to write. Must be less than or equal to the size of buffer, unless buffer is subscripted, in which case we just trust the flags value. If flags=0 (or not specified), writes the entire buffer block. If flags non-zero, the specified number of bytes are written. In order to minimize partial packet writes, we set the send buffer low water mark to match the number of bytes to write, so that we do not start the operation unless the socket buffer has sufficient space. If timer > 0, it waits until the timer expires or the packet is fully written. If timer = 0 and the connection is non-blocking, it returns an error ("EWOULDBLOCK") if the packet cannot be written immediately. Otherwise it waits indefinitely, for the packet to be entirely written or the socket is closed at the other end. This is one case where you might have a problem if you use a packet size larger than the OS supports. |
TCPOP_READ |
Specifies the number of bytes to read. 0 means read whatever is available, from 1 byte to size of buffer. Otherwise, if timer > 0, routine will wait until the required number of bytes is read up to the time limit. If timer = 0 and flags > 0, for non-blocking connections, the flags value is only an upper limit; the routine will return as soon as the interface indicates there is data available even if not the requested number of bytes. For blocking connections, with timer = 0 and flags > 0, the subroutine will wait until the # of bytes is received, or the socket is closed at the other end. If both flags = 0 and timer = 0, for blocking connections it should wait until any data or an error condition is available. For non-blocking connections, the behavior may be platform dependent. Under Unix and Windows, it should return immediately, either with data or with Unix error -11 (resource temporarily unavailable) or Windows error -10035 (a non-blocking socket operation could not be completed immediately). Under some versions of AIX, it has been reported to act the same as for a blocking connection—i.e. waiting until data or some other error is available. If this is a critical concern for your application, you should test it under the platform you'll be using. See the test program TCPTST in EXLIB:[908,25] to simplify your testing. |
TCPOP_SHUTDOWN |
0 indicates a shutdown in both directions. Otherwise, you can shut down just one direction by specifying either TCPXFLG_SHUTRD (32) or TXPXFLG_SHUTWR (64). |
TCPOP_CLOSE |
flags not used. |
TCPOP_CHECK |
If timer specified, flags is ignored and timer is used. If timer not specified, flags specifies how long to wait before returning status 0 if no data avail. If flags is F,6 then it is interpreted as fractional seconds; otherwise it is interpreted as milliseconds. (You should specify timer in all new programs; the option to exclude it is only supported for backward compatibility with TCPCLI and TCPSRV, and is deprecated.) See Asynchronous Client Connections for special considerations involving flags and TCPOP_CHECK. |
TCPOP_CHKQTY |
flags not used. |
TCPOP_CONNECT |
TCPXFLG_BLOCK sets blocking connection (see TCPOP_ACCEPT) TCPXFLG_ASYNC sets asynchronous mode (see Asynchronous Client Connections). |
TCPOP_CONNECT_OLD |
TCPXFLG_BLOCK sets blocking connection (see TCPOP_ACCEPT) |
TCPOP_ERRMSG |
flags not used. |
TCPOP_STARTTLS |
STARTTLS (engage TLS mode) |
TCPOP_WRITE_UDP |
UDP version of WRITE |
TCPOP_READ_UDP |
UDP version of READ |
