Open topic with navigation

TIBCO® Managed File Transfer Platform Server for z/OS 8.1.0

# 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 dataset 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 dataset 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 dataset. 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 datasets. However, the actual volume that the dataset 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 (dataset 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 (dataset 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.

Subtopics

Copyright © 2003-2021. TIBCO Software Inc. All Rights Reserved.