Client applications

The parameters you set for your application can affect performance.

ECI COMMAREA size

The size of the ECI COMMAREA has a large effect on performance. If you make the COMMAREA larger, you need more system resources to process it, and your response times are longer.

The setCommareaOutboundLength method, which is part of the ECIRequest object, is particularly important to performance. The amount of data that an application sends in the COMMAREA flow to CICS® might be small, and the amount of data expected from CICS in return might be unknown. To improve performance significantly, and reduce network loading:
  • Use the setCommareaOutboundLength method to ensure that you send only the required data in the outbound flow to CICS, and not the full Commarea_Length.

    CICS removes any null data from the COMMAREA in the return flow, and the CICS Transaction Gateway automatically pads out the nulls and returns the full COMMAREA to the application.

  • Use the getInboundDataLength method to show the amount of non-null data returned.
  • You can use either the setCommareaInbound method or null stripping. Use setCommareaInbound when the size of inbound data is known in advance.
See ECI performance considerations when using COMMAREAs for more information.

ECI containers

The number and size of ECI containers have an effect on performance. As you increase the number and size of your containers, you need more system resources to process them, and your response times are longer. Load balancing can help control the flow of your data if you use large containers with multiple simultaneous requests across a single gateway.

Synchronous or asynchronous ECI calls

CICS Transaction Gateway has to do less processing to handle a synchronous ECI call than to handle an equivalent asynchronous call. Also, synchronous ECI calls create fewer network flows than asynchronous calls. This means that synchronous ECI calls give better performance than asynchronous calls.

Extended logical units of work

Take care when extending a logical unit of work across multiple program link calls that might span a long time period (for example, user thinking time). The logical unit of work holds various locks, and other CICS resources, on the server. This might cause delays to other users who are waiting for the same locks and resources.

Also, each logical unit of work occupies one CICS non-facility task for the duration of its execution. This means that you must define enough free tasks in the CICS server to service the maximum expected number of concurrent calls.

Parent topic: Performance

Information Information
Feedback


Timestamp icon Last updated: Wednesday, 27 August 2014


https://ut-ilnx-r4.hursley.ibm.com/tgzos_latest/help/topic/com.ibm.cics.tg.zos.doc//performance/topics/ccl99client.html