Problem

difference between SHUT command variations

differences between (and pros/cons):

SHUT

SHUT FAST=YES

SHUT FAST=KILL

Resolution

SHUT will wait all current transfers to complete before shutting down the monitor, new transfer requests will be blocked after the command has been entered.

SHUT FAST=YES will wait for the next checkpoint restart acknowledgement to interrupt active transfers and send to the remote partner a PeSIT information about the fact that the transfer has been stopped on operator request, new transfer requests will be blocked after the command has been entered.

SHUT FAST=KILL newly implemented feature, basically kill all active transfer tasks, implementation may vary, it depends of the platforms. On the CFT for z/os, it is an option in the UCONF file to decide if CFT should be self canceled at shut fast=yes command.

To make your choice:

SHUT can be very long to get CFT stopped, depends of the transfer activity.

SHUT FAST=YES can be also very long to get CFT stopped, it depends of the transfer activity and negotiated PeSIT parameters for each transfer session. It needs manual operation to restart interrupted transfer when CFT is back up again. Manual operation to restart interrupted transfers is the responsibility of the partner when the interrupted CFT is not the requester for those transfers. You no longer have control after CFT restart for such transfers.

SHUT FAST=KILL Interrupt all the activity without any delay. At CFT restart, for transfers where CFT was the requester, a retry is attempted and the transfer is then restarted at latest acknowledged checkpoint. For transfers where CFT was not the requester, the remote partner received a 302 error and is attempting to retry the connection (if the retry parameters are set accordingly), when the CFT is up again, retries are accepted and transfer restarted at the last checkpoint restart acknowledged.

For an unplanned, emergency stop required in a production environment, it is of course SHUT FAST=KILL the more efficient.

• It makes minimum impact at restart time.

• All transfers will be restarted automatically (best case)

• For CFT on z/os, if the version predate the feature to get the product canceled at SHUT time, or, if the UCONF is not set already to get CFT Cancelled, the same result will be obtained issuing a Cancel from the operator console.