|
|
|
This section explains how to code a set of interdependent transfers for CNF configuration files.
The parameter NEWXFER must be used at the beginning of each of the multiple transfer requests, as shown in the following diagram:
...
...
...
transfer request 1 parameters
...
...
...
#==============================
CONTROL=NEWXFER
#==============================
...
...
...
transfer request 2 parameters
...
...
...
#==============================
CONTROL=NEWXFER
#==============================
...
...
...
transfer request 3 parameters
...
...
...
The parameter XTCNET is used to indicate which transfer requests belong to the same group (are dependent on each other). Suppose, for example, that the transfers XFER1, XFER2 and XFER3 need to be grouped together. This can be accomplished simply by assigning the name of the group (say, GROUP1) to XTCNET and including XTCNET=GROUP1 in the definition of each of the three transfer requests.
Each interdependent transfer request must have a unique name, which is assigned to the XTCJOB parameter. Thus, if XFER1, XFER2 and XFER3 are the names of three interdependent transfer requests, their transfer definitions must contain the parameter XTCJOB=XFER1, XTCJOB=XFER2, and XTCJOB=XFER3, respectively.
XTC parameters other than XTCNET and XTCJOB are used to indicate the dependencies obtaining between the transfer requests. The outcome of a transfer request can affect as many as eight other transfer requests. In addition to the XTC parameters, other configuration parameters can (and some, for example, the local file name, must) be used when defining interdependent transfer requests.
HOLD_TRANSFER=YES must be coded in each transfer request that is dependent on the successful/unsuccessful completion of another transfer request (see Example 1).
However, HOLD_TRANSFER=YES need not be coded if the holding/releasing of the transfer request is controlled by the HOLDCOUNT parameter (see Example 2).
You can also define multiple jobs (see Example 3).
CA XCOM Data Transport always protects the password by using encryption. CA XCOM Data Transport encrypts the password in the configuration file and during transmission. A parameter is used to select the cipher that is used for encrypting the password.
The cipher that is used to encrypt the password during transmission is controlled by using the TRNENCRL_CIPHER/STCTRNENCRL_CIPHER and TRNENCRR_CIPHER parameters. Each of these parameters provides a list of ciphers. TRNENCRL_CIPHER/STCTRNENCRL_CIPHER provides the list of requested ciphers for locally initiated connections. TRNENCRR_CIPHER provides a ranked list of permitted ciphers for remotely initiated connections. See the description of the TRNENCRL_CIPHER and TRNENCRR_CIPHER parameters in the XCOM.GLB Parameters section for the full list of the supported ciphers. See the description of the TRNENCRL_CIPHER and STCTRNENCRL_CIPHER parameters in Appendix A: Parameters for the full list of supported ciphers.
When a connection is started to the remote system, the requested list of ciphers for the (STC)TRNENCRL_CIPHER parameter is sent to the remote system. The remote system compares that list with its list of permitted ciphers from the TRNENCRR_CIPHER parameter. The common cipher with the highest ranking on the permitted list is selected to encrypt the password fields during transmission.
Once the cipher is selected a key is generated, the generated key is valid for the current connection only. For the CA XCOM proprietary cipher, a CA proprietary technique is used to exchange the encryption key. For all other ciphers, the key exchange is done using a DH (Diffie-Hellman) key exchange.
When using DH key exchange, the TRNENCRR_DHBITS parameter on the remote system controls the size of the prime number that is used during the key exchange. Consider the following factors when determining the value for the TRNENCRR_DHBITS parameter:
When using the DH key exchange, the secret value that is negotiated is then hashed using the SHA1 hash function to generate the encryption key that is used for the CA XCOM Data Transport connection.
Note: The CA XCOM proprietary cipher is compatible with releases of CA XCOM Data Transport before r11.6. However, releases of CA XCOM Data Transport before r11.6 do not have the capability to negotiate the cipher that is used for password encryption and assumes the use of the CA XCOM proprietary cipher. To allow incoming connections from CA XCOM Data Transport releases before r11.6, include the COMPAT option on the TRNENCRR_CIPHER parameter.
The cipher negotiation can be enabled or disabled by using the COMPAT option of (STC)TRNENCRL_CIPHER.
CA XCOM Data Transport automatically encrypts passwords in transfers, traces, and queue files.
| Copyright © [set copyright date variable] CA. All rights reserved. |
|