Storage requirements for CICS web support
The number of connections that can be sustained between a single CICS® region and the web is primarily limited by the storage available in the CICS region.
The major influences on storage usage for CICS web support are:
- Basic storage requirement for each connection. About 4K of storage is required for each connection between CICS and the Web.
- For CICS as an HTTP server: Size of requests received
from web clients. The total amount of data that CICS accepts
for a single request can be limited by the MAXDATALEN attribute of
the TCPIPSERVICE definition.
- The request line and HTTP headers are stored in a container.
- The request body is stored in CICS main storage. Unwanted data from a request body can be ignored by an application program, but the web attach task always reads the complete message in order to clear the data from the socket, and places all the data in storage.
- Storage used for a request received from a web client is freed when a response has been sent to the request.
- For CICS as an HTTP client: Size of responses received
from web servers. There is no specific way to limit the amount
of data that CICS accepts for a response. (The HTTP client
facility of CICS web support is not designed for use as
a browser, so your requests should return only known resources that
you have selected.)
- The status line and HTTP headers are stored in a container.
- The response body is stored in CICS main storage. Unwanted data from a response body can be ignored by an application program, but the complete message is read and placed in CICS storage.
- Storage used for responses received from web servers is required for the duration of the connection with the web server. The storage obtained for the first response is overwritten by each subsequent response that is received for the connection, or released and re-obtained if a subsequent response requires a larger amount of storage. The storage is freed when the connection is closed by the application program using a WEB CLOSE command (or at end of task if the connection has not previously been closed). The maximum amount of storage that is obtained for each connection is therefore equal to the size of the largest message received on the connection.
- For CICS as an HTTP server and CICS as
an HTTP client: Size of messages produced by CICS (requests
or responses). While a request or response is being assembled
for sending out from CICS, storage is required for the
HTTP headers, and also for the message body.
- The HTTP headers are stored in a container.
- The message body is stored in CICS main storage.
- Storage can be freed in two ways for WEB SEND (Client and Server)
and WEB CONVERSE commands. These options should only be used if you
do not intend (later in this transaction) to retrieve the contents
of the document that has been sent:
- Specify the WEB SEND or CONVERSE command with the ACTION(IMMEDIATE) option.
- Specify the WEB SEND command with the ACTION(EVENTUAL) and DOCSTATUS(DOCDELETE) options.
- Code page conversion. Code page conversion can be carried
out for any message body received or sent by CICS,
if it is specified by an application program, analyzer program, or
URIMAP definition in the processing path for the request. The message
body is in CICS main storage.
- For conversion between the EBCDIC code page 037 and the ASCII code page ISO-8859-1, CICS writes the converted message body to the same area of storage as the original message body, so no additional storage is used.
- For other types of code page conversion, CICS requires additional storage to contain the converted message body. Depending on the character sets used, the size of this additional storage area can range from the same size as the original message body, to a theoretical maximum of four times the size of the original message body (which is unlikely). For example, 2MB of message body data would require at least 4MB of storage in total. Double-byte character sets (DBCS) or multi-byte character sets are likely to require larger storage areas within this range.