Task structure for CICS web support

When CICS® web support is active in a CICS region, for CICS as an HTTP server, separate tasks are used to listen for inbound connection requests; to receive data from the socket and perform initial processing; and to cover work that is carried out by application programs with a request. For CICS as an HTTP client, only one task applies, which is the task for the application program that is making the HTTP requests.

The Sockets listener task (CSOL)

This is a long running CICS task. There is one instance of the Sockets listener task in a CICS system.

The task detects inbound TCP/IP connection requests on all ports that are defined to CICS, and starts the CICS service that is associated with the port. When the port is intended for CICS web support (that is, HTTP or USER is specified as the protocol), the web attach task is defined as the transaction in the TCPIPSERVICE resource definition for the port. The listener either attaches the web attach task, or if the request is eligible directly attaches the user transaction for the request. For more information about which requests are eligible, see Processing HTTP requests by using directly attached user transactions.

web attach tasks (CWXN, CWXU, or an alias)

When the TCPIPSERVICE definition for a port has the protocol HTTP, the default transaction ID for the web attach task is CWXN. When the protocol is USER, the default is CWXU. An alias can be used instead, but the transaction always runs program DFHWBXN.

When a web attach task is started by the Sockets listener task, the first thing it does is to issue a SOCKET RECEIVE request to receive data from the web client. When some data is received, the web attach task deals with initial processing of the web client's request.
  • For an HTTP request (on the HTTP protocol), the initial processing includes URIMAP matching, code page conversion of the HTTP headers, analysis of the request, and code page conversion of the message body. The task also pre-processes chunked and pipelined messages that are received from a web client. If an analyzer program is used, it is covered by this transaction.
  • For a non-HTTP request (on the USER protocol), no initial processing takes place.
If a static response is delivered to an HTTP request (that uses a URIMAP definition), the web attach task handles this processing as well. If an application-generated response is required, the web attach task attaches an alias transaction.

There is a web attach task for each individual request from a web client, which is in the initial stages of processing. Before CICS Transaction Server for z/OS®, Version 3 Release 1, if a web client and CICS had a persistent connection, the CWXN transaction would remain in the system during the persistent connection. Now, the CWXN transaction terminates after a request from the web client is passed to the alias transaction, or after the static response is delivered. The Sockets listener task monitors the socket, and initiates a new instance of CWXN for each request on the persistent connection. This behavior, which is known as an asynchronous receive, avoids the possibility of a deadlock in a situation where the maximum task specification (MXT) is reached, when a CWXN transaction that is remaining in the system would not be able to attach alias transactions to process further requests.

Alias transactions for application-generated responses

When a web attach task completes initial processing for a request, if an application-generated response is to be produced, the web attach task attaches the alias transaction, which is specified for the remaining processing stages of that request. CICS supplies a resource definition for a default alias transaction, CWBA. Alias transactions are not used where a static response is provided. The alias transaction might be attached by the listener task. For more information, see Processing HTTP requests by using directly attached user transactions.

An alias transaction handles the processing stages for an application-generated response, which include receiving the request, running the application's business logic, constructing the HTTP response and code page conversion of the HTTP response. If a converter program is used to process the request, it is also handled by the alias transaction. There is an instance of an alias transaction for each HTTP request, which is in these stages of processing.

CICS as an HTTP client

For CICS as an HTTP client, all activity that is caused by an application program that makes HTTP client requests is covered by a single task. This includes the application program's actions, the actions of CICS in sending requests and receiving responses, and socket activity. If the application program links to other programs using the EXEC CICS LINK command, these are also covered by the task. The task has the transaction ID that triggers the application program.

The task remains in the system from the beginning to the end of the application program's activity. The task might involve more than one request and response, and the application program might open and maintain more than one connection to a server. When the task ends, any open connections are automatically closed.