Changes to CICS-supplied transactions

New CICS-supplied transaction CWXU

In CICS® Transaction Server for z/OS®, Version 3 Release 1, processing for HTTP requests and processing for non-HTTP requests are kept separate. This ensures that CICS can perform basic acceptance checks on HTTP requests and responses, as described in CICS Web support upgrade to HTTP/1.1, and that non-HTTP requests are not subjected to these checks. Processing for non-HTTP requests must now be carried out under the user-defined (USER) protocol, which is specified on the TCPIPSERVICE definition for the port that receives the requests.

The new CICS-supplied transaction CWXU, the CICS Web user-defined protocol attach transaction, is the default when the protocol is defined as USER. CWXU executes the CICS program DFHWBXN. The DFHCURDI sample includes a sample definition for CWXU. An alternative transaction that executes DFHWBXN may be used, with the exception of the other default transactions that are defined for protocols on the TCPIPSERVICE resource definition.

CWXU is a RACF® Category 1 transaction.

Changes to CWXN

There are several changes to the processing carried out by the CICS-supplied transaction CWXN, the Web attach transaction. The most significant of these are:
  • If a matching URIMAP definition is found for an HTTP request, CWXN now invokes the analyzer program only if instructed to do so by the URIMAP definition.
  • Where the HTTP version of the request is HTTP/1.1, CWXN carries out some of the responsibilities of an HTTP server by performing some basic acceptance checks on the request. In response to these checks, CWXN might take action to return a response to the request without involving a user-written application program.
  • CWXN pre-processes chunked and pipelined messages received from a Web client, so that user-written applications do not have to perform this processing.
    • Chunked messages are single messages split up and sent as a series of smaller messages (chunks). CWXN receives and assembles the chunks of the message to create a single HTTP request. CWXN checks that the message is complete before passing it to the user application. The user application can then process the request like any other HTTP request.
    • Pipelined messages are multiple messages sent in sequence, where the sender does not wait for a response after each message sent. A server must respond to these messages in the order that they are received. To ensure this, CWXN holds pipelined requests and releases them one at a time to the user application. The user application must send a response to the first request before receiving the next request from CWXN.
  • Persistent connections are now the default behavior. The connection is only closed if the Web client requests closure, or if the timeout period is reached, or if the Web client is an HTTP/1.0 client that does not send a Keep-Alive header.
  • 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 for the duration of the persistent connection. Now, the CWXN transaction terminates after each request from the Web client has been passed to the alias transaction (CWBA or another transaction), or after the static response has been delivered. The Sockets listener task monitors the socket and initiates a new instance of CWXN for each request on the persistent connection. This behavior, known as an asynchronous receive, avoids the possibility of a deadlock in a situation where the maximum task specification (MXT) has been reached. It also means that the maximum number of concurrent connections between CICS and Web clients is no longer limited by the MXT value, but can in theory be up to 64000. In terms of system activity, if you used persistent connections before CICS Transaction Server for z/OS, Version 3 Release 1, you should now see an increased transaction rate, but a decrease in the number of concurrent tasks.

Priorities for CICS Web support transactions (CWXN, CWXU, CWBA or other alias transactions)

If you set the priority of the CWXN or CWXU transaction higher than the priority of the alias transactions used for application-generated responses (such as CWBA), this can result in a build-up of requests that have been received but not yet processed, which may lead to a short-on-storage situation.

The default priorities for the CWXN or CWXU transaction are set to 1, and the default priority for the CICS-supplied CWBA transaction is also set to 1. You can adjust these priorities depending on your workload. Make sure the priorities of the alias transactions used for application-generated responses (like CWBA) are equal to, or higher than, the priority of the transactions associated with Web attach tasks (like CWXN or CWXU). Bear this in mind if you are setting up your own transaction definitions in place of the CICS-supplied defaults.