Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

How to find out if the file transfer request has been executed

&pagelevel(5)&pagelevel

The command NSTATUS can be used to establish the status of file transfer requests that are not yet complete. On completion of a transfer, the result is stored in a logging record.

It is also possible to use the NCOPY command to request that a result message be generated. There are three ways of generating such a message:

  • allow the result message to be created by the system

  • have a user-generated result message output as follow-up processing

A system-generated message can only be requested in the local system. This is achieved using the LISTING operand which enables you for example to order a result list in all cases (LISTING=*PARAMETER(CONDITION=ANY)), or to order a result list only when the file transfer is aborted due to an error (LISTING=*PARAMETER(CONDITION=ON-FAILURE-ONLY)). The result list can be output to SYSLST or to a file. By default, no result list is created.

If a result list is printed then the user whose user ID was specified in the local TRANSFER-ADMISSION is informed of the termination of the file transfer job by means of an asynchronous message (NOTIFY message in z/OS).

Follow-up processing can also be requested in the NCOPY command. There are four types of follow-up processing:

  • follow-up processing in the local system if the file transfer has been successfully completed

  • follow-up processing in the remote system if the file transfer has been successfully completed

  • follow-up processing in the local system if the file transfer has been aborted because of an error

  • follow-up processing in the remote system if the file transfer has been aborted because of an error.

Follow-up processing after a successful file transfer can be defined for both systems by the operand SUCCESS-PROCESSING, while that following a failed file transfer is defined by FAILURE-PROCESSING.

If follow-up processing is to take place under a different user ID from that specified by TRANSFER-ADMISSION, then that user ID can be specified using the PROCESSING-ADMISSION operand.

Example

In this example described in the previous section the CLIST procedure
'CAESAR.MISTAKE.CLIST' is to be executed in the local system under the ID CAESAR with the account number ACCT0003 and the password ABCDEFGH if the file transfer was not successful. In addition, a result list is to be printed under the ID FRED with account number ACCT0001 (without a password). If the file transfer has been successful, a message is to be sent to the user BERT in the remote system with account number ACCT0002 and password P1234567. In addition the file is to be assigned the name DATA and stored under the user ID BERT.

NCOPY

TRANSFER-DIRECTION=TO,

PARTNER=VAR001,

LOCAL-PARAMETER=(FILE=DATA,

    TRANSFER-ADMISSION=(USERIDENTIFICATION=ANTON,

        ACCOUNT=ACCT0001,PASSWORD=HUGO),

    PROCESSING-ADMISSION=(USER-IDENTIFICATION=CAESAR,
        ACCOUNT=ACCT0003,PASSWORD=ABCDEFGH),

    FAILURE-PROCESSING='EX IRRTUM',LISTING=*SYSLST),

REMOTE-PARAMETER=*MSP(FILE=DATEN,

    TRANSFER-ADMISSION=(USER-IDENTIFICATION=BERT,

        ACCOUNT=ACCT0002,PASSWORD=P1234567),

    SUCCESS-PROCESSING='SEND ''FILE TRANSFER O.K.'',USER(*)')

A possible short form of this command is as follows:

NCOPY TRANS=TO,PARTNER=VAR001,

LOC=(FILE=DATA,TRANS=(ANTON,ACCT0001.HUGO),

PROC=(CAESAR,ACCT0003,ABCDEFGH),FAIL='EX IRRTUM'),

REM=*MSP(FILE=DATEN,TRANS=(BERT,ACCT0002,P1234567),

SUCC='SEND ''FILE TRANSFER O.K.'',USER(*)')

The commands defining follow-up processing must be enclosed in single quotes. Any quotes specified within the command must be doubled (see SEND command in the example above).

If neither a result list nor follow-up processing has been requested for a request, you can use the logging function to determine whether the request has been carried out. A request may generate up to four logging records:

  • an FT logging record in the initiator system on request termination. A precondition for this is that the request has been correctly accepted by openFT and FT logging is active.

  • an FT logging record in the responder system on request termination. A precondition for this is that the actual file transfer operation has already been concluded and FT logging is active.

  • an FTAC logging record in the initiator system on acceptance of the request. A precondition for this is that openFT-AC is used in the initiator.

  • an FTAC logging record in the responder system on acceptance of the request. A precondition for this is that openFT-AC is used in the responder.

You view logging records with FTSHWLOG.