Appendix F. User Exits

The platform server currently supports six types of user exits.

EXIT00: End of Transfer Exit

At the successful or unsuccessful completion of a file transfer, the platform server for z/OS can branch to a user exit called FUSEX00.

TIBCO MFT Platform Server for z/OS provides a copy of its internal queue record. The exit program can analyze the record, and perform any tasks such as displaying additional messages or updating a user file. Any updates to the queue record are ignored by the platform server because this exit is intended as an informational record only.
Note: This exit is invoked for temporary network errors and each transfer retry.

EXIT01: Transfer Authorization Checking Exit

Before performing its data set authorization checking, the platform server for z/OS can branch to a user exit called FUSEX01.

As input to its exit, the platform server provides a copy of its internal queue records. At the time of the call to the user exit, the SAF ACEE points to the user ID associated with the transfer. FUSEX01 can then perform additional security validation to ensure that the user is authorized to use the platform server or to access the data set in question. This user exit is called for:
  • File, job, and report transfers
  • Initiator transfer and responder transfer

This exit is invoked at transfer execution time. It is therefore possible for a user to queue a transfer successfully, yet with the transfer failing at execution time.

EXIT03: HSM Migration Exit

With the HSM migration exit, you can perform actions when an HSM migration volume is detected by the platform server.

In addition to the GLOBAL EXIT03 parameter, the following two GLOBAL parameters define when and how EXIT03 is invoked.
  • EXIT_MIGRATE_VOLUME
  • EXIT_MIGRATE_WAIT_TIME
At the start of a transfer, the platform server checks the catalog for the volume associated with the data set. User EXIT03 is called only if the following conditions are met:
  • GLOBAL EXIT03=YES.
  • The volume matches the GLOBAL EXIT_MIGRATE_VOLUME.
  • The volume does not match the GLOBAL HSM_MIGRATE_VOLUME.

DMS (CA Disk™ Backup and Restore Utility) uses a pseudo volume ARCIVE for archived data sets. However, the actual volume that the data set resides on is MIGRAT. In this case, to call EXIT03 you must ensure HSM_MIGRATE_VOLUME parameter does not equal MIGRAT and the EXIT_MIGRATE_VOLUME parameter is equal to MIGRAT.

As input to this exit, the platform server provides a copy of its internal queue records. Based on the return code, the platform server performs the following functions:
Return Code Server Response
0 Continue processing.
1 Wait for the interval defined by the GLOBAL EXIT_MIGRATE_WAIT_TIME. If the catalog volume changes within this interval, the platform server processes the request. If the catalog volume does not change within this interval, the request is terminated with an error.
4 The request is treated as a temporary error and retried at the next retry interval.
> 4 The request is treated as permanent error and will be terminated.

EXIT04: Responder Preallocation Exit

The preallocation exit is called for responder transfers, just before the platform server allocating a file. It is called before the user ID and password is verified, and just after CFALIAS processing is performed.

With this exit, you can do the following:
  • Terminate the transfer.
  • Change these properties of a file transfer: local file name (data set name), or file status and disposition.
As input to this exit, the platform server provides a copy of its internal queue record. Based on the return code, the platform server performs the following functions:
Return Code Server Response
0 Continue processing with no changes.
1 The user exit has changed the local file name or the file status and disposition. The platform server will use these changes in the current transfer.
8 The request is treated as permanent error and will be terminated.
other The request is treated as permanent error and will be terminated.

EXIT05: Purge from Queue Exit

At the successful or unsuccessful completion of a file transfer when the transfer is purged from the queue, the platform server can branch to a user exit called FUSEX05.

The platform server provides a copy of its internal queue record. The exit program can analyze the record, and perform any tasks such as displaying additional messages or updating a user file. Any updates to the queue record are ignored by the platform server because this exit is intended as an informational record only.
Note: This exit is not invoked for temporary network errors until the RETRY parameter is exceeded and the transfer request is purged with completion status of unsuccessful.

EXIT06: Add to Queue Exit

This exit is called at the time a transfer request is queued to the server.

With this exit, you can do the following:
  • Terminate the transfer.
  • Check the specified transfer parameters.
  • Change the following properties of a file transfer.
    • Effect (create, replace, append, create/replace, create/append, create/replace/new)
    • Encryption
    • Compression
    • Local file name (data set name)
    • Remote file name
    • Description
    • Local user
    • Remote user
    • Remote password
    • Return code
    • Last message
    • Process name
    • Date eligible
    • Time eligible
    • Execution priority
    • Hold transfer
    • Remote system
As input to this exit, the platform server provides a copy of its internal queue record. Based on the return code, the platform server performs the following functions:
Return Code Server Response
0 Continue processing with no changes.
1 The user exit has changed transfer parameters. The platform server will use these changes in the current transfer.
8 The request is treated as permanent error and will be terminated.
other The request is treated as permanent error and will be terminated.