For the SELECT function call, you must create six equal size arrays. The first three arrays pass data to the SELECT function. The last three arrays are responses from the call. Within each set of three arrays, there is a read, write, and exception array. Each array is actually a series of bits set either on or off, depending on which sockets are being processed. Because this bit string is not in what would be considered a standard order, and because bit strings are hard to handle in COBOL, IBM has provided an additional subroutine, EZACIC06, to convert a character array into the correct bit array. It also will perform the reverse to enable a COBOL program to examine the returned information. The character array is a set of 1-byte flags that represent each socket and must be set to either “0” or “1” (x’F0’ or x’F1’). When examining these flags, the very first character represents socket zero, so the index is actually “socket number plus one.” Lines 97 through 111 of Figure 5 show the actual coding to use EZACIC06.
To use the SELECT call to prevent an RECV lock-up, the program needs to set the flag in the RSNDMSK that corresponds to the socket number returned from the original SOCKET call. Lines 8 through 11 of Figure 12 show how the flags are set. Lines 17 through 23 show how the returned values are examined.
In addition to the flag arrays, you need to indicate the highest number socket you will want the function to examine (line 7) and the timeout value (lines 2 and 3). Once the call returns, you need to know whether the call completed due to data being received or due to a timeout. The SELECT call returns the number of sockets to be processed in retcode. If this is zero, then no sockets are ready and you know that a timeout condition occurred.
A SIMPLE SERVER
In the client example, the CONNECT call is used to connect to a server. To convert a client program into a server program, you need to replace the CONNECT with a series of calls that create the server environment and then accept connections from clients.
Creating the Server Environment
Before a client program can connect to a server program, the server program must tell the IP stack that it plans to service a specific port and that it is available to service connection requests. It does this by issuing a BIND followed by a LISTEN.
The BIND call tells the IP stack on which IP port the server wants to accept connections. As in the CONNECT call, this is done using a “name” data area. Where the CONNECT passes both a port and ipaddress, a BIND uses only the port number field. Lines 112 through 121 of Figure 5 show an example of a BIND.
A LISTEN call tells the IP stack to actually start listening for connection requests against the port passed in the BIND call. Lines 122 through 128 of Figure 6 show an example of a LISTEN call.