Problem

After a very high CPU usage several transfers aborted

CFTT82E transfer aborted 740 ABO 317

CFTI01F CFT error _ Maximum process CFTTFIL running reached

Many 302 and 240 RTO errors

Resolution

Transfer CFT is of course sensible to a system high CPU consumption that result in a system slowing down affecting most if not all applications.

The file-transfer activity involve timing that can result in timeout for any partner side when exceeded.

Also, after an effective system slow down, a restart of an heavy loaded CFT adds to the pic of CPU usage and will tends to use a lot of resources in respect of the CFT parameters.

Oversized or wrongly chosen Transfer CFT parameters can work without an issue until a delayed activity due to a system resources shortage results in troubles to manage the pending transfer load.

The spikes of the CPU usage is known as one source of 240 RTO errors;

Active transfers turn delayed and get the RTO expired when CPU is back available.

Such delay may also affect the remote partner that can in its turn, also detect a RTO after having sent a chuck of data (resulting in 740 ABO 317 errors).

For small files transfers, often, the time needed to open the session can be even more than the time needed for the transfer itself.

After a CPU shortage CFT can be highly busy in dealing with all incoming calls and restarting interrupted transfers.

In general, very high CPU usage slow down applications. CFT, when suffering of this, will take longer to manage sessions opening and get transfer activity restarted.

Transfer CFT should be treated as a TP application meaning non swap-able and highest priority (same as a CICS TP application)