z/OS Communications Server: IP IMS Sockets Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


GIVESOCKET and TAKESOCKET calls

z/OS Communications Server: IP IMS Sockets Guide
SC27-3653-00

The GIVESOCKET and TAKESOCKET functions are not supported with the IMS™ TCP/IP OTMA Connection server. Tasks use the GIVESOCKET and TAKESOCKET functions to pass sockets from parent to child.

For programs using TCP⁄IP for MVS™, each task has its own unique 8-byte name. The main server task passes three arguments to the GIVESOCKET call:
  • The socket number it wants to give
  • Its own name 1
  • The name of the task to which it wants to give the socket
If the server does not know the name of the subtask that will receive the socket, it blanks out the name of the subtask. 2 The first subtask calling TAKESOCKET with the server’s unique name receives the socket.
The subtask that receives the socket must know the main task’s unique name and the number of the socket that it is to receive. This information must be passed from main task to subtask in a work area that is common to both tasks.
  • In IMS, the parent task name and the number of the socket descriptor are passed from parent (Listener) to child (MPP) through the message queue.
  • In CICS®, the parent task name and the socket descriptor number are passed from the parent (Listener) to the transaction program by means of` the EXEC CICS START and EXEC CICS RETREIVE function.

Because each task has its own socket table, the socket descriptor obtained by the main task is not the socket descriptor that the subtask will use. When TAKESOCKET accepts the socket that has been given, the TAKESOCKET call assigns a new socket number for the subtask to use. This new socket number represents the same connection as the parent’s socket. (The transferred socket might be referred to as socket number 54 by the parent task and as socket number 3 by the subtask; however, both socket descriptors represent the same connection.)

Once the socket has successfully been transferred, the TCP/IP address space posts an exceptional condition on the parent’s socket. The parent uses the SELECT call to test for this condition. When the parent task SELECT call returns with the exception condition on that socket (indicating that the socket has been successfully passed) the parent issues CLOSE to complete the transfer and deallocate the socket from the main task.

To continue the sequence, when another client request comes in, the concurrent server (Listener) gets another new socket, passes the new socket to the new subtask, and dissociates itself from that connection. And so on.

1 If a task does not know its address space name, it can use the GETCLIENTID function call to determine its unique name.
2 This is the case in IMS because the Listener has no way of knowing which Message Processing Region will inherit the socket.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014