What is the shortest form of the NCOPY command?
In order to send a file to a partner system, it is usually sufficient to issue the following command. The entries to be replaced begin with lowercase letters:
/TFF TO,partner,(file),(,,transAd)
TFF is an abbreviation for the TRANSFER-FILE (NCOPY) command. The same effect is, of course, also achieved with the alias NCOPY, for example.
Any FTAC transfer admission defined in the remote system (e.g. TRANSADM) may be entered for transAd. Alternative input: (user,acc,passwd).
You can also use the same entry for partners on Unix systems, provided, of course, that you do not object to entering the file name in uppercase letters in Unix systems.
The entry will also work for Windows partners, provided the file name is syntactically allowed there.
And what if a library member is to be transferred?
/TFF TO,partner,((lib,elem,type)),(,,transAd)
The file name must be replaced by (lib,elem,type). Note, however, that this input form does not apply to Unix and Windows partners, since no libraries are present there. You should therefore enter the following:
/TFF TO,partner,((lib,elem,type)),(file,,transAd)
or
/TFF TO,partner,((lib,elem,type)),A('file',,'transAd')
Please note that you should generally always specify only guaranteed abbreviations in procedures (e.g. *ANY instead of A) to remain independent of the current FT version being used.
Do I need to specify LIST=*NONE in NCOPY?
No. This entry is the default setting to suppress the result list.
How do I determine which FT requests have succeeded and which ones have failed?
The logging records output by:
/SHOW-FT-LOG
shows you the result of the last transfer.
If you want to view the last n entries, specify:
/SHOW-FT-LOG ,n
The most recent entry is displayed first.
You can also select logging records using different criteria (e.g. partner, file name, etc.). Note that when openFT-AC is used, two entries are recorded for each TRANSFER-FILE request: the first entry is the FTAC entry, which is identified by a C in the first column, and the second entry, which follows the first, contains the result of the transfer (identified with T).
If you want to see only the results of the transfer, enter:
/SHOW-FT-LOG (REC-TYPE=(,N)),n
The messages FTR2025, FTR2076 or FTR2199 DMS ERROR return a non-DMS RC as the return code. Why?
These messages are issued whenever the local or remote file management system issues a return code (on a file access error) that cannot be mapped to one of the more informative FTR messages (e.g. FILE UNKNOWN, FILE NOT SHAREABLE). This may be potentially caused by two problems:
The remote file management system need not be the BS2000 DMS (it may be a Unix system or a Windows system, for example).
The transmission protocol only provides for standardized return codes, so your file transfer does not receive the original return code generated on the partner - even if the remote system happens to be a BS2000 system.
Consequently: DMS error simply means an error from the (respective!) file management system, and the return code contains the code forwarded by the transmission protocol.
In such cases, it is often worth trying to copy the file with a normal COPY command (possibly on the local and remote system), since the internal system RC would then be received in the event of an error.
How does one detect whether an error has occurred on the local or remote system?
The following rules apply:
If the TRANSFER-FILE command is not accepted with FTR0000, but is rejected immediately instead, the error always lies on the local system.
For TRANSFER-FILE commands that are rejected after being accepted with FTR0000, the error is almost always on the remote system. As of openFT V10, it is also possible to identify the origin of the problem from the message. If the reason for the rejection is FTR2169 Remote system: Transfer admission invalid, the cause in this case always lies in the remote system.
In cases where the partner cannot be reached at all (e.g. FTR0108), the situation is more ambiguous, and there is generally no way of knowing on which side the problem occurred.
How can I easily determine whether or not a partner can be reached?
It is generally not advisable to test an FT connection using the NCOPY command, since the request is processed asynchronously, and the result is therefore not immediately visible. A much simpler test can be performed using:
/SHOW-REM-FILE partner
If the partner cannot be reached, you will immediately receive a corresponding message.
If the partner can be reached, your request will be rejected by the partner with FTR2169 (since you did not specify a transfer admission or specified an invalid transfer admission), with FTR0020 or FTR2027 (since no file was specified) or with FTR2170 (since the partner does not support file management).
This test can be performed independently of the operating system.
Can I determine the name of a file on the remote system?
Yes. The command
/SHOW-REM-FILE partner,*DIR('.'),,transAdm
shows you all files on the partner system, or more precisely, all files that you may access under the specified transfer admission transAdm.
Restriction: The '.' entry is not supported by older FT-BS2000 versions. Use *DIR($userid.) in such cases.
If desired, you can also have all members of a library displayed with:
/SHOW-REM-FILE partner,*DIR('lib/typ'),,transAdm
How can I wait for the result of a transfer before proceeding with a procedure?
By specifying a MONJV, assuming, of course, that your system has monitoring job variables. Enter the command:
/NCOPY TO,partner,(file,MONJV=jv),(,,transAd)
/WAIT (jv,2,1) EQ 'T' OR (jv,2,1) EQ 'A',TIME=sec
NCOPY starts the transmission. The WAIT command then waits for a maximum of sec seconds for the transmission to complete. If the operation terminates normally, the job variable is assigned a 'T' at the second position; if an abort occurs, an 'A'.
Another possibility is to use synchronous transfer with FTSCOPY (TRANSFER-FILE-SYNCHRONOUS).
Why was my FT request rejected even though I entered a correct transfer admission?
It is indeed possible for a request to be rejected despite a correctly specified transfer admission (in the form (user,accout,password), for example) or TRANSADM. This is because your request could also be rejected if the transfer admission does not allow you to execute all the actions you want. Here are some potential reasons:
The user ID is locked on the remote system (e.g. by SEVER/LOCK-USER in BS2000).
The remote system is not allowing any requests which use transfer admissions of the form (user, account,password), since all levels in the FTAC admission set have been set to 0.
The desired direction of transfer or your system was rejected by the partner.
The partner system does not allow the desired function, e.g. follow-up processing or even file management.
In addition, the transfer admission is often specified in uppercase instead of lowercase, and vice versa, especially when given over the phone. Uppercase letters can be effectively specified only within quotes.
Finally, it is possible that the transfer admission you specified was really invalid.
My call was rejected with FTR2169 Remote system: Transfer admission invalid. How do I find out the reason?
The rejection comes from the partner system. Consequently, the cause can only be determined there.
With openFT products, the reason can be easily determined from the FTAC logging record.
To do this, ask your partner to display the last logging record or the last n logging records under the receiving ID:
In BS2000 with
/SHOW-FT-LOG [,n]In z/OS with
FTSHWLOG [,n]In a Unix system and a Windows system with
ftshwl [-nb=n]or via the respective graphical user interface.
Using the partner, file name, time, etc., as reference points, you will first need to look for the matching FTAC entry (type C or FTAC). The reason for the rejection will be given in the RC column. The meaning of the RC is output directly on a graphical user interface; it can be explicitly requested with /HELP FTCnnnn in BS2000 and with fthelp nnnn in Unix system or Windows system (where nnnn is the RC).
If your partner cannot find any logging record for your request, you have either not contacted the correct partner, or the specified transfer admission does not belong to the expected receiving ID. This could be primarily because the transfer admission does not exist (especially if you entered it incorrectly, for example).
What is an FTAC transfer admission and how can I set one up?
The normal way to identify oneself on a remote system is via the logon entries, i.e., the user ID, account number (only under BS2000 and z/OS) and password:
Operand TRANSFER-ADMISSION=(user-id,account,password).
A simpler method is to use a special authorization exclusively for the file transfer. This is named FTAC transfer admission or shortly transfer admission (TRANSFER-ADMISSION=transAdm). In order to avoid exposing all the details of his/her entire logon authorization, the owner of the transfer admission sets up a so-called admission profile as follows:
In BS2000:
/CREATE-FT-PROFILE name,,transAdmIn z/OS:
FTCREPRF name,,transAdmIn a Unix system or a Windows system with
ftcrep name transAdmor via the respective graphical user interface with File / New / Admission Profile.
In the above entries, name is the name under which the profile can be administered (e.g. deleted again) and may be up to 8 characters in length. transAdm is the admission which is assigned by the partner and which you specify in your FT command, and must be at least 8 characters. If blanks or other special characters appear in it or if a distinction between uppercase and lowercase letters is to be made, the entry must be enclosed within single quotes.
Under BS2000 and z/OS, admission profiles can be set up only on systems with openFT-AC.