Some servers handle multiple request types. An iterative server can spawn different children, depending on the request type. There are several ways to determine which child process to spawn. One way is for the server to actually listen on multiple ports. Another method is for the request type to be contained in the first few bytes of the data initially sent to the server. The API provides a method where the server can examine the first few bytes of data without actually receiving the full datastream or causing it to be destroyed. The child process can then request the IP data and still receive all the data originally sent by the client. This is referred to as “peeking” at the data and is done using a modified RECV request. Lines 138 through 146 of Figure 6 show such a request.
You must consider security for requests. One method to secure a transaction is to check the IP address of the client against a list of authorized IP addresses. You can access the client IP address using GETPEERNAME. This will return a “name” area, which was described earlier when I discussed the RECV request. Lines 147 through 153 of Figure 7 show such a call. A GETPEERNAME request can be combined with a RECV request for efficiency by using a RECVFROM call. Lines 154 through 162 of Figure 7 show an example of this. You can also use the RECVFROM call to peek at the data using the same flag as a standard RECV. Such a call is shown on lines 163 through 171.
SERVER/CHILD A concurrent server handles multiple connections by creating a child process. In CICS, this would be done via an EXEC CICS START TASK command. The child is normally responsible for sending and receiving all data.
Starting the new transaction to process the data under CICS is actually easy. However, transferring the socket from the parent server to the child server involves several steps. The four functions needed are GETCLIENTID, GIVESOCKET, SELECT, and TAKESOCKET.
The GETCLIENTID (lines 172 through 178 of Figure 8) is required to retrieve the name assigned to your server by the IP stack. The child is required to know this information before it can take the socket. The returned name will be transferred to the child as part of the EXEC CICS START TASK command.
The GIVESOCKET (lines 179 through 187 of Figure 8) call informs the IP stack that the socket is being transferred to another program. The GIVESOCKET does not wait until the child takes the socket, but returns immediately. The server then starts the child task and must issue a SELECT call using the “exception” flags. Once notified that the child has successfully taken the socket, the parent will need to issue a standard CLOSE against the socket.
Once the child program starts, it should perform the normal INITAPI call. It will then use the data passed in the EXEC CICS START command to perform a TAKESOCKET call. Once the call returns, the socket number to be used by the child will be found in retcode, just like a SOCKET call. Lines 188 through 198 of Figure 8 show an example of a SOCKET. Figure 15 shows the code for a basic child program.
Due to the complexity of a concurrent server and magazine space limitations, an example of such a server is not shown here, but can be downloaded from www.vse2pdf.com/coolstuff. The program BSTTEZ11 handles concurrent ACCEPT, GIVESOCKET, and RECV requests using a single SELECT. The program BSTTEZ13 is the child program. This is how the SELECT call was designed to be used. You can also find sample batch programs, BSTTEZ01, BSTTEZ02, and BSTTEZ03 on the Website. These represent a concurrent server, a client, and a child program. The child program actually runs in a separate partition as a separate job.
At the Website mentioned, you will also find downloadable copies of useful IBM manuals. The Redbook is no longer available from IBM, and is a little dated, but is the best manual I have seen for the beginning mainframe IP programmer.