TransferCFT InstallationGuide Windows en

Transfer CFT
Version 3.3.2
28 July 2020
User Guide
Windows

Copyright © 2018 Axway
All rights reserved.
This documentation describes the following Axway AMPLIFY software:
Transfer CFT 3.3.2
No part of this publication may be reproduced, transmitted, stored in a retrieval system, or translated into any human or
computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or
otherwise, without the prior written permission of the copyright owner, Axway.
This document, provided for informational purposes only, may be subject to significant modification. The descriptions and
information in this document may not necessarily accurately represent or reflect the current or planned functions of this
product. Axway may change this publication, the product described herein, or both. These changes will be incorporated in
new versions of this document. Axway does not warrant that this document is error free.
Axway recognizes the rights of the holders of all trademarks used in its publications.
The documentation may provide hyperlinks to third-party web sites or access to third-party content. Links and access to
these sites are provided for your convenience only. Axway does not control, endorse or guarantee content found in such
sites. Axway is not responsible for any content, associated links, resources or services associated with a third-party site.
Axway shall not be liable for any loss or damage of any sort associated with your use of third-party content.
Contents
Preface 1
About Transfer CFT 1
Installation guide outline 1
Who should read this guide 2
Transfer CFT documentation set 2
Support services 2
Accessibility 3
Accessibility features of the documentation 3
Screen reader support 3
Support for high contrast and accessible use of colors 3
1 Prerequisites 5
Overview 5
License keys 5
End User License Agreement 6
Check your authorization 6
System requirements 7
Supported operating systems and browsers 7
Disk space and RAM requirements 7
Java 7
Installer screen resolution 7
Windows-specific prerequisites 8
Windows requirements 8
User rights prerequisites 9
Run as administrator 10
Service mode prerequisites 10
Cluster installation requirements 10
Default ports 13
Certificates 14
Shared file system prerequisites 14
Standalone installation 14
Active/passive cluster 14
Active/active cluster 15
2 Install 16
Before you start 16
Installation package contents 16
Installation functions 16
Transfer CFT 3.3.2 Installation and Operation Guide 3

Installation modes 16
Run as administrator 17
Installed directories 17
Install Transfer CFT 17
Start the installation 17
Cluster mode screens 22
Auto import (for migration) 24
Multi-node options 25
Governance options 27
Connector options 27
Installing services in command line 28
Cluster installations 29
Silent mode installation 33
Install active/active - Windows 38
Prerequisites 38
Overview 38
Install the cluster nodes 39
Integrate Transfer CFT in a Microsoft Cluster Service (MSCS) 40
Install active/passive - Windows 46
Prerequisites 47
Install 47
Integrate Transfer CFT in a Microsoft Cluster Service (MSCS) 48
Installer functions 55
Installer functions 55
JRE customization 58
3 Post installation 61
Installed directories 61
Perform an update 61
Create a basic configuration 61
Update the profile 61
UCONF 62
Configuration 62
License key 62
Transfer CFT internal datafile and configuration 62
User interface configuration 63
Configuration for Service Mode 63
Start the Transfer CFT Copilot server 63
Start Transfer CFT 63
4 Update, upgrade or migrate 64

Start here: Upgrade, update, and migration 64

Updates versus upgrade or migrate 64
Update or upgrade using Central Governance 66
Important information 66
Determine the installer and product version 66
Check product details 67
Update Transfer CFT 68
Download the update file 68
Check product details 68
Impacted directories when updating a product 68
Use Central Governance for updates 68
Windows users 69
Install patches and service packs 70
Uninstall patches and service packs 71
Install patches and service packs in a multi-node, multi-host environment 72
Upgrade Transfer CFT 73
About upgrades 73
Before you start 73
Use Central Governance to upgrade Transfer CFT 74
Upgrade Transfer CFT 2.6.4 to 3.3.2 75
Upgrade Transfer CFT 3 .1.3 to 3.3.2 83
Upgrade Transfer CFT 3 .2.2 to 3.3.2 84
Post upgrade 85
Upgrade a Transfer CFT multi-node installation 86
Before you start 86
Upgrade from Transfer CFT 3.0.1 multi-node 87
Upgrade from Transfer CFT 3.1.2 multi-node 89
Post upgrade 91
How to free disk space from service packs 91
Use the purge command 91
Perform a manual migration 92
Migration prerequisites 92
Install and auto import 94
Migrating from Transfer CFT 2.3.2 to 3.3.2 97
Migrating from Transfer CFT 2.4 to 3.3.2 100
Migrate from Transfer CFT 2.5 or 2.6 to 3.3.2 105
Migrating Transfer CFT 2.6.4 SP2 or 2.7 to 3.3.2 107
Migrating Transfer CFT 3.0.1 or 3.1.x to 3.3.2 109
Migrating Transfer CFT 3.2.x to 3.3.2 114
Activate Central Governance connectivity 120
Overview 120
Automatically activate connectivity 120
Manually activate connectivity 121

Connect to a different Central Governance system 124
Use former configuration objects 124
View managed features 124
Post-migration procedure 126
Post manual migration or auto import 126
Post-manual migration only 126
Post upgrade 127
5 Uninstall 128
About uninstalling in Windows 128
6 Create a product deployment package 130

Install a template Transfer CFT 130
Generate the Express Package 131
Customize the Express Package 132
Install the Express Package 134
Limitations 134
7 Troubleshooting 135
Troubleshoot installation and registration 135
Copilot server issues 135
Central Governance 135
Transfer CFT server 136
Applying a license key 136
Obtain a license key 137
Apply a license key 137
About command 138
Support tools /contact Support 138
Accessing the Axway Support site 138
Using cft_support 139
8 Operations 141
About Windows operations 141
Transfer CFT Windows specific operations 141
Product presentation 141
About Windows operations 141
Transfer CFT c ommunication systems 142
Applying a license key 143
Running Transfer CFT for the first time 144
Set the environment 145
Start Transfer CFT using a command 146
Shut down Transfer CFT using a command 146
Start or stop Transfer CFT using a user interface 146
Service mode 147

Start the CFTW desktop window 147
Running Transfer CFT for the first time 147
Transfer CFT user interfaces 150
Defining user rights Windows 151
Using system users Windows 158
Specific network functions 160
Define additional environment variables 161
About Windows-specific system functions 161
About environment variables 161
About Windows-specific system functions 162
Environment variables in Windows 163
Symbols and default files 164
Transferable files 165
General o perating functions 167
Communication media 170
File management functions 171
Automated functions 178
Trace functions in CFT Windows 180
Setting protocol parameters 181
Setting up the TCP/IP layer 181
Defining TCP/IP parameters 181
About Windows Application Programming Interfaces (API) 184
Constraints 185
About Windows Application Programming Interfaces (API) 187
Building API in Visual Basic 190
Building an API in C 192
Developing exits 194

Preface
This documentation provides information to aide you in installing, updating, upgrading, or
migrating Transfer CFT.
About Transfer CFT

Transfer CFT is the file transfer component in the Axway Managed File Transfer solution, and
provides a multi-platform, high-volume, file and message transfer service. This documentation
explains how to install, configure, and manage Transfer CFT.
Using version 3.1.x or higher, you can configure Transfer CFT and manage flows using Axway
Central Governance. Central Governance simplifies Transfer CFT usage, and provides services such
as identity and access management, certificate management, monitoring, alerting, and a web
dashboard.
For more information on Axway products, visit www.axway.com.
Installation guide outline

This guide explains how to perform a full installation of Transfer CFT. It also describes how to:
Prepare and plan your installation – Describes what you should plan for deploying and

configuring your system architecture, installing any prerequisite software, and configuring other
components.
Install – Describes how to perform a complete install as well as apply a service pack.
Post installation – Provides instructions on how to check if the installation was successful and set
up Transfer CFT. Additionally it describes any tasks to perform before the administrator can log on to
the product for initial configuration.
Upgrade – Involves a change in product version and the replacement of binary artifacts; may also
require configuration change.
Migrate– Involves a change in product versions, such as from 2.7.1 to 3.3.2. As part of this
process, the existing configuration may need to be modified or updated to be compatible with the
new version. For example, you may need to modify configuration files or the internal datafile
schema. Because migration can be a complex process, organizations typically set up a migration
project to study the new features and determine the impact on the existing configuration, and to
plan for the changes across the various environments.
Uninstall – Describes how you can uninstall Transfer CFT.

Preface
ExpressPackage - Describes how to create a product package that you can deploy to multiple
remote sites.
Troubleshoot the installation or registration process – Describes the different types of

troubleshooting errors you can encounter during installation, upgrade and post-installation.
Who should read this guide

This guide is intended for enterprise personnel involved in installing software and Axway
Professional Services personnel. Familiarity with AMPLIFY products is recommended.
This guide presumes you have knowledge of:
l Your company’s business processes and practices
l Your company’s hardware, software, and IT policies
l The Internet, including use of a browser
Others who may find parts of this guide useful include network or systems administrators and other
technical or business users.
Transfer CFT documentation set

Transfer CFT provides a complete set of documentation, covering all aspects of using the product.
These documents include the following:
l Transfer CFT 3.3.2 Release Notes
l Transfer CFT 3.3.2 User Guide (HTML)
l Transfer CFT 3.3.2 Local Administration User Guide
l AMPLIFY Supported Platforms Guide
l AMPLIFY Interoperability Matrix
Support services
The Axway Global Support team provides worldwide 24 x 7 support, subject to validation of your
license agreement. Email support@axway.com or, for your local support telephone number, visit
support.axway.com and click Contact Axway Support.

Accessibility
At Axway, we strive to create accessible products and documentation for all of our users.
This section describes the accessibility features of the documentation.
Accessibility features of the documentation

The product documentation provides the following accessibility features:
l Screen reader support
l Support for high contrast and accessible use of colors
Screen reader support

l Alternative text is provided for images whenever necessary.
l The PDF documents are tagged to provide a logical reading order.
Support for high contrast and accessible use of

colors
l The documentation can be used in high-contrast mode.
l There is sufficient contrast between the text and the background color.

Accessibility
4 Installation and Operation Guide Transfer CFT 3.3.2

Prerequisites
1
Overview
Axway p roducts are delivered electronically from Sphere, the Axway support website. A welcome
letter notifies you that your products are ready for download.
To install you will perform the following tasks:
1. Check your license key and authorization.
2. Check the hardware and system requirements.
3. Download product.
4. Install products.
License keys
Before installing or upgrading, make sure you have obtained a license for Transfer CFT. Check that
the license key is correct for the features and operating system you intend to install. It is not
mandatory to enter the license key during the Transfer CFT installation, but you do require a key to
start the product.
For information on applying a license key post installation, or if you have a problem with your
license key, refer to the appropriate Troubleshooting topic. Depending on your OS, see:
l Windows: Applying license key
l UNIX: Applying a license key
l z/OS Applying a license key
l IBM i Applying a license key
Multi-node license keys

Transfer CFT in a multi-node architecture requires:
l One key per node, and if there is more than one host you require at least one valid key per host
l Each key must have the cluster option
As of Transfer CFT 3.3.2 SP2, you can use a single key for a multi-node installation. To use a single
key for multiple hosts, either:

1 Prerequisites
l The hostname must not be defined for the key, or
l The hostname defined for the key matches the hostname of one of the hosts that composes the
multi-node instance
Additionally, the key must have the cluster option.
Example
If you have 2 hosts and 4 nodes, you require 4 keys with at least one key per host. Possible key
combinations could be:
l 2 keys that are configured to reference the first host, and the 2 other keys configured to
reference to the second host
l 3 keys that are configured to reference the first host, and 1 that is configured to reference to
the second host
Transfer CFT in a multi-node architecture requires a shared file system for use of a multi-node
architecture on several hosts (active/active). Additionally, the system must be configured prior to
the multi-node installation, and the shared disk ready when starting the Copilot server.
l Windows only: You must map the shared disk to a drive letter. Windows UNC is not
supported.
l Windows only: The Copilot Service Mode cannot be started as the LocalSystem
account.
l Windows only: If you are running Copilot in Service Mode, you must set up a
dependency with the shared disk's service for multi-node.
End User License Agreement

You should read and accept the End User License Agreement (EULA) prior to installing Transfer CFT.
The EULA file is in the directory where you decompressed the Transfer CFT package.
Check your authorization

Verify that you can access Axway support at support.axway.com and log in. If you do not have an
account, follow the instructions in your welcome letter.
Log in to download or access:
l The product installation package
l Your product license key
l Product documentation
l Product updates, including patches and service packs
l Product announcements
l Axway Supported Platforms Guide
l The case center, to open a new case or to track opened cases

1 Prerequisites
System requirements
The following are the system requirements for Transfer CFT.
Supported operating systems and browsers

Refer to the Axway Supported Platforms Guide for more information.
Disk space and RAM requirements

Transfer CFT has the following hardware requirements:
l Disk space requirement
o 1.5 to 5 Gigabyte: minimum disk space to allow for future updates, SPs, and continued
performance
l RAM Requirement
o 128 Megabyte: minimum dedicated per host
Java
The Transfer CFT Copilot client is based on Java technology. To avoid compatibility issues Axway
provides the correct JRE, which is installed during the product installation in the <Axway
home>/java/<platform name>/jreX directory, where jreX represents the Java version.
Clients that connect to Copilot require Java 8. If you intend to implement EBICS (UNIX/Windows) or
Secure Relay you also require Java 8.
Java 8 is delivered with the product, with the following exceptions:
l Java 7: linux-s390-32, linux-s390-64, sun-sparc-32, sun-x86-32
l Java 6: hpux-parisc-32, hpux-parisc-64, linux-ia64-64
Secure Relay Java installation directory prerequisite
When using Secure Relay, Java must be installed in the same environment as the Transfer CFT
installation. The Master Agent is thus managed, while the Router Agent can be in another
environment.
Installer screen resolution

When the Installer is run in GUI mode, a resolution of at least 800 x 600 is required.

1 Prerequisites
Windows-specific prerequisites
The following are tasks to perform or issues to address before installing Transfer CFT.
Windows requirements
The Windows installation directory must not contain any sub-folders or files that are owned by
another user.
Hardware and software requirements

Before installing Transfer CFT Windows check the following:
l OS version
l Communication system type
These selections affect the minimum hardware and software requirements for the product and may
be inter-dependent.
Transfer CFT is based on an external network layer, which must be installed before operating the
product. And note that if other applications are running at the same time as Transfer CFT, the RAM
requirement needs to be increased.
Apply a service pack or patch, or upgrade using Central

Governance
To upgrade or install a Transfer CFT Service Pack or patch from Central Governance, you must:
l Run the Transfer CFT UI (Copilot) as administrator.
l Disable the Windows User Account Control (UAC).
Configure Windows UAC

User Account Control (UAC) is an option to add security infrastructure on Windows operating
systems.
For Windows versions that support UAC, Windows Vista, Windows Server 2008, Windows 7,
Windows Server 2008 R2, and Windows 2012, you must disable the UAC when using Central
Governance to apply patches, service packs or upgrades for Transfer CFT.
1. From the Start menu, type UAC and click to search.
2. In the User Control Account settings pop-up window, set the slider to Never Notify.

1 Prerequisites
3. Click OK.
4. Reboot to make the change effective.
For Windows versions prior to the versions listed above, p erform the following steps to add yourself
in Log on as a service group:
1. Navigate to Start > Control Panel > Administrative Tools > Local Security Policy.
2. From the tree, select Local Policies > User Rights Assignment > Log on as a service.
Note On some systems the path may be Start > Control Panel > System and Security >
Administrative Tools > Local Security Policy.
Set administration rights if UAC is enabled

If you do not disable the UAC, the installer requires administration rights at installation. You must be
part of a group of administrators, or have an administrator user account. The installer detects the
type of user, and sends the appropriate message:
l Setup with administrator user account: Accept or decline if you want to make changes to your
computer.
l Setup with standard user account: Enter your administrator password first to continue.
Tasks that required elevated rights

The following tasks require that you have elevated rights and fail if one of the above setup options
was not performed:
l Create or remove shortcuts in Start menu or desktop
l Create or remove Windows services
l Installing in %SystemRoot% or %ProgramFiles%
l Running product scripts that require elevated rights
Windows x86 operating system prerequisites

When using a Windows x86 (32-bit) or (64-bit) system, you must install the Visual C++
Redistributable Package for Visual Studio 2013 ( not a later version) to provide necessary
library files (DLL) for the compiler:
l For a win-x86-32 target use: vcredist_x86.exe
User rights prerequisites

There are certain Windows-specific tasks you must perform to enable system user authentication
and file system rights before using Transfer CFT or Copilot.
The following sections in the Defining user rights Windows on page 151 page describe how to:

1 Prerequisites
l Define rights before starting the UI server (Copilot/REST API/Transfer CFT UI)
l Define rights before logging on the Transfer CFT UI server (Copilot)
l Define rights before starting Transfer CFT
l Define a domain user
l Define folder rights
l Define system user access
Run as administrator
The user who installs or upgrades Transfer CFT must be an administrator on the system where you
are performing the installation.
Service mode prerequisites

Note the following prerequisites and limitations when installing Transfer CFT in service mode.
l If you install Transfer CFT in service mode, to launch the service on a specific account you must
grant that user service rights to log in.
To grant this right, navigate to Administrative Tools > Local Security Policy > Local
Management > Local Policies, and select User Rights Assignment. Then grant the user
Logon as a Service.
l If you install Transfer CFTin service mode but want to launch the service on a Local System
Account, be aware that you cannot start Transfer CFT from the Copilot UI.
Cluster installation requirements

Because you cannot use a UNC path (\\address\folder) as a shared directory, when installing a
Transfer CFT cluster the shared directory must be located in a mounted shared drive (u:\folder).
This is due to UNC path support limitations, such as the changedir function, which are needed by
Transfer CFT server. Transfer CFT cannot start up properly if the CFTDIRRUNTIME environment
variable is set to a UNC path.
A best practice therefore, when using Transfer CFT clusters in Windows, is to install Transfer CFT in
cluster mode and permanently map the network shared directory to a drive. Using this method, the
mapped drive is then accessible to the Transfer CFT Windows Services. There is no need to modify
the Transfer CFT profile after the installation.
See also, Shared file system prerequisites on page 14.

1 Prerequisites
Create a mapped drive

This section describes how to create a mapped drive using the psexec tool. You require this step
when installing an active/active cluster, but it can be used for a standalone installation.
To map network shares to a drive accessible to Windows Services, you must log in as the NT
AUTHORITY\SYSTEM account.
1. Download the Sysinternals Suite from Microsoft, and unzip it to a directory.
2. Open a command window and start a session as Administrator (Run as administrator).
3. Go to the unzipped directory containing the Sysinternals Suite executable:
CD <the_previously_unzipped_directory>
4. Log in as the NT AUTHORITY\SYSTEM account:
psexec -i -s cmd.exe
Note This launches a new command window. Perform the next step in this new window.
5. In the new window, create the persistent mapped drive.
net use Z: \\servername\sharedfolder /persistent:yes
6. Provide the credentials for a user having access to the shared folder.
7. Create a Startup script that contains only the command from step 5 (Create the persistent

mapped drive), and implement using the instructions in the Microsoft article: Assign Computer
Startup scripts.
Remove a mapped drive

To remove a mapped drive:
1. Launch a command prompt as Administrator (run as administrator).
2. Go to the unzipped directory containing the Sysinternals Suite executable with command:
CD <the_previously_unzipped_directory>
3. Login as the NT AUTHORITY\SYSTEM account:
psexec -i -s cmd.exe
Note This launches a new command window. Perform the next step in this new window.
4. In the new window, delete the mapped drive:

1 Prerequisites
net use Z: /delete

1 Prerequisites
Default ports
The following list contains the default Transfer CFT port numbers used for installation. You can
check in advance that these ports do not conflict with ports used by other applications on the same
machine.
You may need to modify the default port numbers, depending on your configuration.
The Internet Assigned Numbers Authority (IANA) reserves the TCP ports 1761-1768 for Transfer
CFT. For more information, refer to: www.iana.org/assignments/service-names-port-
numbers/service-names-port-numbers.
Component Port
PeSIT 1761
SSL 1762
COMS 1765
Copilot 1766
Copilot for Central Governance 1767
REST API 1768
Central Governance 12553
Central Governance SSL 12554
Secure Relay MA
ma.comm_port 6801
Secure Relay RA
l ra.comm_port l 6811
l ra.admin_port l 6810
Legend:
l PeSIT (PESITANY protocol): PeSIT in plain text
l SSL: PeSIT protocol over SSL/TLS
l COMS: Synchronous transfers
l Copilot: Provides access to Transfer CFT Copilot server from a user Internet browser
l Copilot for Central Governance: Provides secure access for Central Governance (mutual
authentication)
l Central Governance: Used to connect to Central Governance

1 Prerequisites
Certificates
Using the default certificates that are supplied with Transfer CFT is strongly discouraged in a
production environment. You should use your own certificates to enhance security.
Type Location Certificate Expires
Secure <Transfer_CFT>/home/distrib/xsr SecureRelayCA.pem November

Relay 2021
SecureRelayMasterAgent.p12 November
2021
Central <Transfer_ passportCA.pem November

Governance CFT>/runtime/conf/pki 2019
Shared file system prerequisites

This section provides general information concerning the prerequisites for shared file systems for the
following types of files used with Transfer CFT in a Windows environment.
l Transfer CFT data files: This refers to all files managed by Transfer CFT other than transferable
application files (including database files), which are stored in the Transfer CFT runtime
directory.
l Transferable application files: This refers to the files transferred by Transfer CFT.
Standalone installation
You can use any POSIX compliant shared file system for both Transfer CFT data files and transferable
application files.
Active/passive cluster
application files.

1 Prerequisites
Active/active cluster
Transfer CFT data files

Supported shared file systems for multi-node, multi-host architecture (active/active)
The following non-exhaustive table lists shared file systems that have been tested with Transfer CFT.
Operating Supported Unsupported

system
AIX GPFS (recommended), NFSv4 NFSv3, CXFS, VeritasSF
HP-UX NFSv4 NFSv3, CXFS, VeritasSF
Linux-x86 GPFS (recommended), GFS2, NFSv3, CXFS, ACFS, OCFSv1, OCFSv2,

NFSv4, AWS EFS QFS, VeritasSF
OpenVMS RMS
Solaris NFSv4 NFSv3, CXFS, QFS, VeritasSF
Windows-x86 CIFS CXFS, NFS
z/OS Sharing DASD across Sysplex
Transfer CFT transferable application files

You can use any POSIX compliant shared file system for transferable application files.

Install
2
Before you start
If you are installing Transfer CFT as part of a managed file transfer solution, you may want to check
the installation order and prerequisites. For more information, please refer to the Central Governance
documentation.
During the installation process you are prompted to select if you want to enable Central Governance.
Please check that your license includes Central Governance and that you have the required
information, such as the shared secret, to activate connectivity.
Before you start the installation, you should:
l Downloaded the installation package from Axway Sphere.
l Uncompressed or unzipped the package.
Note See also Windows x86 operating system prerequisites on page 9 for p rerequisites including

DLL requirements for x86.
Installation package contents

The installation package is a zip archive. Once you unzip it, it contains the product and installer
program files.
Installation functions
The installer is used to install, configure, update and uninstall Transfer CFT. You can run the
following installation modes:
l Install
l Configure
l Update
l Uninstall
Installation modes
Locate and run the setup file in the root folder of the installation package.
GUI mode
setup32.exe or setup64.exe

2 Install
Console mode
setup32.exe -m console or setup64.exe -m console
The setup32.exe is a 32-bit build executable and will run on a 64-bit platform provided that the
compatibility layer has been installed.
Run as administrator
The user who installs Transfer CFT must be an administrator on the system where you are performing
the installation.
Installed directories
Once you install a product, the following sub-directories are installed.
l Configuration: Includes the configuration file for each installed product
l Documentation: User documentation
l Installer: Files used by the installer
l Java: The deployed JRE used by the installer and Axway products
l SilentFile: Includes the silent file for each installed product
l synInstall: Installer internal files that are used to manage the installed infrastructure
l Tools: Tools used by the installer to manage infrastructure instances. You can use some of
these for example, XDBM and SilentFileEditor
l Transfer_CFT: the product folders and files
Note If the redistribution package is already installed on your Windows system, there is no need
to reinstall.
Install Transfer CFT
Start the installation

You can use this topic to plan and execute installation of Transfer CFT. If you are using Adobe
Reader, you can add comments to document the data you need to enter after launching the
installer. Otherwise, you can print the topic, enter data manually and use the notes when installing.
Once you have completed planning, you are ready to install. See the section About the installer for
details on how to start the installer in install mode.
To configure Transfer CFT for installation, perform the following procedure. Pending your license
key options and environment, however, you may have only a subset of the following screen
selections.

2 Install
This table displays a basic installation, a standalone Transfer CFT, with no options.
Screen Description
Welcome Provides links to the Axway website and Sphere, the Axway support site.
License Select the check-box "I accept..." to continue with the installation.
agreement
Installation Select to install on either a single machine, or a cluster mode installation.
architecture Note If you select cluster, additional screens display.
Installation Where product files and documentation will reside.
directory
Axway Transfer Specify the directory where you want to install Transfer CFT.
CFT: By default, Transfer CFT is installed in a sub-directory o f the Axway
Installation installation directory. Use the default directory, or specify a new directory.
directory Directory paths cannot contain spaces.
Axway Transfer Specify the directory where you want to install the Transfer CFT runtime
CFT: directory.
Runtime By default, the runtime directory is installed in a sub-directory of the
directory Transfer CFT installation directory. Use the default directory, or specify a
new directory. A runtime directory will be created if it does not already
exist.
Directory paths cannot contain spaces.
Axway Transfer Specify if you want to import data from an existing Transfer CFT by
CFT: Auto selecting Yes.
Import You can install and import configuration and data from v2.3.2, v2.4, v2.5,
v2.6, v2.7, v3.0.1, v3.1.3-3.2.x.
Note If you select Yes in the Auto Import screen, additional
screens display.
Axway Transfer Check or modify the supplied information concerning the Transfer CFT
CFT: instance name, group name, and host address.
Identity An asterisk * denotes that these fields are mandatory.

2 Install
Screen Description
Axway Transfer Select to enable multi-node architecture.
CFT: Multi-node Enter the number of nodes. The first node is zero, and you may have up to
Architecture eight nodes.
Enter the host name and address for each node. You must enter at least one
host.
Note If this is a cluster installation and you enable the multi-
node option, the Transfer CFT will be an Active/Active
installation. Otherwise, the installation is an
Active/Passive installation.
If you select multi-node, additional screens display.
Axway Transfer Enter the license key for the Transfer CFT product.
CFT: If you have a license key issued for a previous version of Transfer CFT, enter
License key your license key in the License Key field and select the Check key o ption.
You can configure up to eight keys.
Deselect Check key to continue with the installation without a key.
However, you cannot run Transfer CFT until you supply the license key.
Note If you are installing in multi-node you require:
l One (1) valid key per node (see details in multi-node section)
l Among the keys there must be at least one valid key per host
Axway Transfer Please specify a seed password to generate the encryption key:
CFT: Generate l Password: Enter and then confirm a password that contains at a
Encryption Key minimum 8 characters, containing at a minimum an upper and lower
case letter, a number, and a supported special character (such as +*?!
etc.)
l Key and salt files: Use the proposed file locations or enter the path to
the desired location to store these file.
Axway Transfer Enable Central Governance connectivity:
CFT: l Yes: Install Central Governance connectivity. For details, see the
Governance Central Governance topics in the Transfer CFT User's Guide.
Mode
l No: Installs Transfer CFT without Central Governance.

2 Install
Screen Description
Axway Transfer Enter the TCP parameters for the host, PeSIT protocol, catalog, and
CFT: communication media.
Configuration
l Synchronous communication: enter the COMS port
l PESITANY: Enter the PeSIT protocol port number
l Select the default database size:
o Catalog: Modify the default catalog file size
o Communication File: Modify the default communication file size
Axway Transfer Enter the Transfer CFT UI Server values:
CFT: Interface
l Listening Port: Listening port for the graphical user interface. This sets
Servers
the port on which the Transfer CFT UI server listens for incoming TCP
connections.
l Listening CG Dedicated Port: Defines a dedicated listening port for
Central Governance. This field displays only if you enabled Central
Governance connectivity.
l Enable REST API Server: Enter the server port (or use the default) if
you plan to use REST APIs.
Note If you enabled multi-node, you are also prompted for the load balancer
details.
Axway Transfer For Windows installations, specify whether you want to start Axway
CFT: Server Transfer CFT manually, or to have Windows start and stop it as a Windows
startup mode service. Select:
l Normal mode: You must manually start and stop the Transfer CFT
server
l Service mode: Windows automatically starts and stops the Transfer
CFT server. If you select this option, the next installer screen sets the
Service parameters.
Note: To start Transfer CFT server using service mode from the Copilot
server, it is imperative that Transfer CFT service be set up with a
specific user account (not using the default system user). If the user is
the system user, the Copilot will not be able to start Transfer CFT in
service mode.

2 Install
Screen Description
Axway Transfer For Windows installations, specify whether you want to start Transfer CFT
CFT: UI Server UI manually, or to have Windows start and stop it as a Windows service.
startup mode Select:
l Normal mode: You must manually start and stop it.
l Service mode: Windows automatically starts and stops it. If you select
this option, you use the next installer screen to set Service parameters.

Axway Transfer If you selected Service mode, enter values for the Windows service
CFT: UI Server parameters:
service l Service Name: Enter a Windows service name
l Display Name: Enter a Windows service display name
You can accept the default Service names o r modify them. The installer
uses these names to create a Transfer CFT service entry in the Windows
registry.
l Start Type: Automatic, Manual, Disabled
l Error Control: Ignore, Normal, Severe, Critical
l Use specific account to start the service: Enables you to use a local
account instead of a system account
l Domain: Enter the domain name
l Username: Name of the local account
l Password: Enter the user password
Note: In multi-node, to start the Transfer CFT server using service mode
from the Copilot server, it is imperative that Transfer CFT service be set up
with a specific user account and domain (not using the default system
user). If the user is the system user, Copilot will not be able to start Transfer
CFT in service mode.
Axway Transfer This screen enables you to install Start Menu shortcuts.
CFT: l Yes: Creates shortcuts
Shortcuts
l No: Does not create shortcuts
This screen enables you to install desktop shortcuts.
l Yes: Creates shortcuts
l No: Does not create shortcuts

2 Install
Screen Description
Axway Transfer This screen allows you to select from the following Axway product
CFT: connectors:
Connectors l Sentinel
l Public Key Infrastructure with PassPort
l Access management with PassPort
Note If you select any of the available connectors, additional
screens display.
Axway Transfer Click Install to complete the installation process, or Previous to review or

CFT: modify installation options.
Ready to install
Cluster mode screens

Screen Description
Installation Select either:
architecture o Single - Installs Transfer CFT on a single machine.
o Cluster - Installs Transfer CFT on several machines. Select this option if you
want to install Transfer CFT in multihost/multi-node or in active/passive
mode.
If you are performing a cluster installation and you enable the
multi-node option, this creates an active/active Transfer
CFT installation. Otherwise, the installation is active/passive.
Cluster o First node: Install on a first machine before adding additional machines
(nodes). You must install on a first node before you can select the option
to install on additional nodes.
o Additional nodes: After installing on the first machine, you can select this
option to install on an additional machine(s).
Installation Specify the root shared directory (shared disk) where the Axway installer
directories programs will reside, and the root installation directory where the product files
and the documentation will reside.

2 Install
Screen Description
Axway Specify the directory where you want to install Transfer CFT. This directory will
Transfer store all of the Transfer CFT binaries.
CFT: By default, Transfer CFT is installed in a sub-directory o f the Axway installation
Installation directory. Use the default directory, or specify a new directory.
directory Select the directory that will store shared data between Transfer CFT machines.
for Transfer It will contain the Transfer CFT runtime.
CFT
Axway Specify the directory where you want to install the Transfer CFT runtime
Transfer directory.
CFT: By default, the runtime directory is installed in a sub-directory of the Transfer
Runtime CFT installation directory. Use the default directory, or specify a new directory.
directory A runtime directory will be created if it does not already exist.

2 Install
Auto import (for migration)

If you select Yes in the Auto import screen, the following Installer pages display.
Screen Description
Axway Transfer Specify if you want to import data from an existing Transfer CFT by
CFT: Migration selecting Yes or No.
You can migrate from V2.3.2, V2.4, V2.5, V2.6, v2.7, v3.0.1, v3.1.x or
v3.2.x.
Axway Transfer Specify the path to the profile file.
CFT: Migration
Axway Transfer This screen is only displayed during a migration operation. You should see
CFT: Migration the Version, SP, Installation directory and runtime directory display on the
Options screen.
Select the objects that you want to import:
For V2.5.x and higher:
l Functional configuration objects (PARM/PART)
l Environment objects (UCONF)
l Catalog: CFTCATA
l Communication medium: CFTCOM
l Local PKI base (as of V2.5.1 - SP2)
For V2.4.x:
l Environment objects (Sentinel: trkapi.cfg)
l Environment objects (Copilot: copconf.ini)
l Catalog (CFTCATA)
l Communication medium (CFTCOM)
l Local PKI base (as of V2.4.1 - SP6)
For V2.3.2:
l Environment objects (Sentinel : trkapi.cfg)
l Catalog (CFTCATA)
l Communication medium (CFTCOM)
You have to migrate the following objects manually:
l Executables
l Exits
l APIs

2 Install
For more information on importing configuration and data, see Install and auto import.
Multi-node options
A multi-node installation architecture allows installing Transfer CFT binaries on several hosts,
physical or virtual server, and Transfer CFT runtime files on shared file system.
The multi-node feature allows for executing multiple Transfer CFTs (called Transfer CFT nodes) on
one or several hosts. The set of Transfer CFT nodes is called a Transfer CFT instance. See the Cluster
installations topic and the Manage multi-node section for details.
Screen Description
Axway Transfer Select to enable multi-node architecture.
CFT: Multi-node Enter the number of nodes. The first node is zero, and you may have up to
Architecture eight nodes.
Enter the host name and address for each node, up to eight nodes. You
must enter at least one host.
l If you are performing a cluster installation and you enable the multi-
node option, this creates an active/active Transfer CFT installation.
Otherwise, the installation is active/passive.
l If you did not perform a cluster installation, selecting the multi-node
option creates a local, multi-node installation.

2 Install
Screen Description
Axway Transfer Enter the license key for the Transfer CFT component.
CFT: If you have a license key issued for a previous version of Transfer CFT,
License key enter your license key in the Key field and c heck the Check key o ption.
You can configure up to eight keys.
Deselect Check key to continue with the installation without a key.
However, you cannot run Transfer CFT until you supply the license key.
Transfer CFT 3.3.2 SP2 and higher
As of Transfer CFT 3.3.2 SP2, you can use a single key for a multi-node
installation. To use a single key for multiple hosts, either:
l The hostname defined for the key matches the hostname of one of the
hosts that composes the multi-node instance
For example, if you have 2 hosts and 4 nodes, you only need one key that
matches one hostname (or no defined hostname).
Transfer CFT prior to 3.3.2 SP2
If you are using a Transfer CFT 3.3.2 prior to SP2, multi-node architecture
requires:
l One key per node, and if there is more than one host you require at
least one valid key per host
For example, if you have 2 hosts and 4 nodes, you require 4 keys with at
least one key per host. Possible key combinations could be:
l 2 keys that are configured to reference the first host, and the 2 other
keys configured to reference to the second host
l 3 keys that are configured to reference the first host, and 1 that is
configured to reference to the second host
Back to core installation screens (Governance Mode).
For more general information on using multi-node features refer to the Transfer CFT User's Guide, in
the topic About multi-node architecture.

2 Install
Governance options
Screen Description
Axway Transfer CFT: Central This screen is only displayed if you enabled Central Governance
Governance connectivity connectivity. Enter values for the following parameters:
l CG Host Address: Sets the server hostname on which the
connector will connect
l CG Port: Sets the port on which the connector will connect
l Specify Custom Certificate: If selected, enter the certificate
to authenticate Central Governance.
l Shared Secret
l Confirm Shared Secret
l Configuration Policy
For general information on Central Governance, see the Governance services topic in the Transfer
CFT User Guide.
Connector options
Screen Description
Axway Transfer CFT: Specify the connectors that you want to configure and activate:
Connectors l Sentinel
l PKI with PassPort
l Access Management with PassPort
Transfer CFT: This screen is only displayed if you enabled Sentinel connectivity. Enter
Sentinel Connector values for the following parameters:
l Sentinel Host Address: Sets the Sentinel server hostname on which
the connector will connect to
l Sentinel Port: Sets the Sentinel Server port on which the connector
will connect to
Connector parameters
l Log Filter
l Transfer Filter: Select the level of information, warning, error and
fatal messages you want to receive: All, Summary, No
l Enable Sentinel Heartbeat: Check to enable

2 Install
Screen Description
Transfer CFT: This screen is only displayed if you enabled PassPort PKI connectivity.
PassPort PKI Enter values for the following parameters:
connector l PKI Server Host Address: Sets the PassPort server hostname on
which the connector will connect.
l PKI Server Port: Sets the PassPort PS port (PS socket server port, or
PS secure socket server port) on which the connector will connect.
o Use SSL
o PKI server public certificate
o Copy certificate
o PKI server login
o PKI Server Password
o Confirm PKI Server Password
Transfer CFT: This screen is only displayed if you enabled PassPort AM connectivity.
PassPort Access Enter values for the following parameters:
Management l AM Server Host Address: Sets the PassPort server hostname on
connector which the connector will connect.
l AM Server Port: Sets the PassPort AM server port (API server, or
secure API server) on which the connector will connect.
o Use SSL
o AM Server public certificate
o Component instance
o Domain
o Component Login
o Component Password
o Confirm P assword
Installing services in command line

Windows only
Transfer CFT services

1. To install the Transfer CFT service, access the Transfer CFT directory:
cd %TransferCFT_directory%

2 Install
2. Enter the following:
cscript /nologo home\bin\cftsrvin.vbs n=CFT332
Where n= <CFT plus the current version of Transfer CFT>
Copilot services
From the Transfer CFT home directory, run:
copsrv.exe -install <service_name> <displayname> <cftdirruntime>
Example
For Transfer CFT version 3.3.2 Copilot you would enter:
c:\CFT332\Transfer_CFT\home\bin>copsrv.exe -install CFT_Copilot332 CFT_

Copilot33
c:\CFT332\Transfer_CFT\runtime
Cluster installations
This section describes the recommendations when installing a Transfer CFT c luster architecture.
Before starting a new Transfer CFT multi-node installation though, check the prerequisites and
Release Notes. See also the User Guide section Manage multi-node architecture.
Note Active/passive shared disks must be POSIX compliant.
Overview
A multi-node installation architecture allows installing Transfer CFT binaries on several hosts,
physical or virtual server, and Transfer CFT runtime files on shared file system.
The multi-node feature lets you execute multiple Transfer CFTs (called Transfer CFT nodes) on one
or several hosts. The set of Transfer CFT nodes is called a Transfer CFT instance.
A combination of both features provides following possibilities:
l A single installation of Transfer CFT with multi-node (HA).
l Install Transfer CFT using the Single installation architecture of the Axway Installer and enable
the multi-node architecture.
l Only one execution of the installation procedure is needed.
l Transfer CFT binaries and runtime files must be installed on a shared file system in order to be
accessed from several hosts.
l Both binaries and runtime files are shared.
Note To patch Transfer CFT binaries, the Transfer CFT instance (all of Transfer CFT nodes) must
be completely stopped.

2 Install
Prerequisites
When installing a Transfer CFT cluster, the user performing the installation must:
l Be a domain user who is part of the Administrators group.
l Be the same user for all machines.
l Have all rights (create/modify/delete) to the shared disk on all machines when Transfer CFT is
installed in a multi-host architecture.
Platform and shared file system support

Transfer CFT supports multi-node architecture on Windows-x86. See also Shared file system
prerequisites on page 14.
Active/active multi-node (HA) installation

A cluster installation of Transfer CFT with multi-node (HA)
l Install Transfer CFT using the Cluster installation architecture of the Installer and
enable the multi-node architecture (in the Axway Transfer CFT: Multi-node
Architecture screen).
l Installation procedure must be executed on each host:
o The first host installation (meaning the first node as defined in the Axway
Installer) sets the Shared directory, the <Transfer_CFT Shared> directory and
all of the Transfer CFT configurations.
o During each hosts installation (meaning additional nodes as defined in the
Axway Installer), you are prompted to specify the shared directory, and all
parameters from the first installation will be automatically loaded.
l Transfer CFT binaries are installed on several hosts and runtime files are installed on a
shared file system.
l Only runtime files are shared.
l At any given time:
o One or several hosts are active.
o All Transfer CFT runtime environments (Transfer CFT nodes) are running.
Note Transfer CFT binaries can be patched on each host one after the other without stopping the
Transfer CFT instance (all of the Transfer CFT nodes).
Active/passive cluster installation

A cluster installation of Transfer CFT without multi-node is an active/passive installation as described
below:

2 Install
l Install Transfer CFT using the Cluster installation architecture of the Axway Installer and disable
the multi-node architecture ( in the Axway Transfer CFT: Multi-node Architecture screen).
o The first host installation (meaning the first node as defined in the Axway Installer) sets
the Shared directory, the <Transfer_CFT Shared> directory and all of the Transfer CFT
configurations.
o During each hosts installation (meaning additional nodes as defined in the Axway
Installer), you are prompted to specify the Shared directory, and all parameters from the
first installation will be automatically loaded.
l Transfer CFT binaries are installed on several hosts and runtime files are installed on a shared file
system.
l You must configure the cluster after installation but before you can use the cluster. The
procedure for cluster configuration varies depending on the platform on which the cluster is
installed.
o Only one host is active
o Only one Transfer CFT runtime environment is running on the active host
Note Transfer CFT supports all POSIX file systems.
Install the cluster nodes

There are two general steps for installing a product in a cluster.
1. Install the first node in the cluster.
2. Install additional nodes in the cluster.
After installation, but before you can use the cluster installation, you must configure the cluster for
high-availability operations. The procedure for cluster configuration varies depending on the type of
platform on which the cluster is installed.
Install first node in cluster

Use this procedure to install the product on the first node in a cluster:
1. Launch the installer on the machine that supports the first node.
2. On the Installation architecture page, select Cluster and click Next.
3. On the Cluster page, select First node and click Next.
4. On the installation directories page, specify values for the following and click Next.
Note After installing applications in active/passive mode, you must implement the cft start, cft

stop, and cft status scripts for the cluster.
Shared Directory

2 Install
This is the path and name of the directory where you want to create a shared directory for the cluster
installation. The shared directory is used to store product data files.
The installer proceeds with the standard sequence of pages for the product.
Installation Directory
The path and name of the local directory where you want to install the first cluster.
Install additional nodes in a cluster

Use this procedure to install the product on additional nodes in a cluster:
1. Launch the installer on the machine that hosts the additional node.
3. On the Cluster page, select Additional nodes and click Next.
Shared directory
Path and name for the shared directory that you entered for the first node. The shared directory is
used to store product data files.
The installer installs the product on the second node and configures the shared directory for sharing
between the installed nodes.
Integrate Transfer CFT in a Microsoft Cluster Service

(MSCS)
Prerequisites
Transfer CFT must be installed in service mode.
Define Transfer CFT as a Generic Service Resource

Transfer CFT is a cluster-unaware application. However, you can integrate Transfer CFT in a cluster
environment as a Generic Service Resource. Use the Microsoft High Availability Wizard to create
a Generic Service, and from the Select Service dialog box select the Transfer CFT service.
License key
The Transfer CFT license key refers to a specific machine, and is based on the machine's hostname.
To allow Transfer CFT to start on both cluster nodes, you need one license key per node. Enter the
two license keys in the %CFTKEY% file located on the shared disk, one key per line.

2 Install
Silent mode installation

Note Windows only. If you have implemented a firewall, deactivate the firewall prior to
installation in silent mode.
Silent mode enables you to perform an installation or configuration in a non-interactive mode. You
do not have to enter any parameters in the GUI or console.
To use this mode, you must install the product or run the installer program and perform
configuration until just before you click Install. Then in your home installation directory you will
have the silent file template you can use to duplicate installations on other machines.
Silent file concepts

The purpose of using a silent file is to quickly duplicate an installation on multiple machines without
running the installer and entering the same parameters over and over again.
The installer's silent mode takes these values from existing or generated silent files. Before you can
use this procedure, you must have the necessary silent files available. You can generate these files
by installing a product at least once by completing the dialogs up until the point of clicking Install.
Creation
A silent file can be created:
l After an installation
or
l After completing the installer dialogs up until the point of clicking Install
The installer's SilentFile directory contains the properties file (Install_Axway_Installer_
V4.10.0.properties) and the product property files you might need to install. You must not modify
anything in this file except the InstallDir,InstallationLogicalName and list of IncludeFiles. The
product property files cannot be used outside of the main installer file.
The installer embeds some security features. For this reason if you want to execute silent
installations, you must enter the required passwords during the initial installation.
Location
The silent file is created in:
<install directory>\SilentFile\<InstallationDateTime_Action>\<Install_
ProductShortName_V<Version>.properties
Where:
l InstallationDateTime corresponds to Year_Month_Day_Hour_Minute_Second.
l Action corresponds to the action done, for example if you performed an install or configure.

2 Install
Variables
A silent file is a collection of parameters in the form of key-value pairs, each on one line. The variable
stores the name of the parameter (it is the key) and the value stores the other string.
The structure of a variable inside the silent file is:
Variable = Value
Note The extra spaces around the variable are trimmed.
Some special types of variables can be identified.
Variable.Property = Value
Variable.Default = <LinkToAnotherVariable> | Value
A variable property signifies or provides some additional information about that specific variable
(commonly known as metadata; it might be used for validation purposes, for parsing purposes,
etc.).
For example, information on the creation date:
CreationDate = 13-02-2010
CreationDate.Format = dd-MM-yyyy
Specify the creation date of the silent file (currently, the date the silent file was last modified by the
build tool – effectively the date of the build used by the current kit) and below, the format used to
parse this date variable (the format used by the date variable).
If a value is missing, the installer takes the default value instead. If the default value links to another
variable, the link is replaced by the value of the linked variable (this is called a feedback link).
Encrypted variables
For security reasons, some variables (passwords) are encrypted in the silent case. This means the
Format property contains the used encryption algorithm (default is plain).
l If you want to change the value of an encrypted variable, you must use the silent file editor tool
l You can disable the encryption of the variable by deleting the Format property
Environment variables
If you need to deploy a product installation on several machines, with only a few changes to make
on the installation parameters, use the same silent file. In the silent file you can replace the
unwanted parameters with environment variables that you defined on your machine before the
installation. You can then use these variables instead of the Variable Values.
You can use environment variables when installing or configuring in Silent mode (limited to Silent
mode only.)

2 Install
l Windows: %env_var%
There are restrictions for certain variables and therefore you cannot use an environment variable for
the following parameters:
l Component properties
l Variable properties
l Installer variables (in the file Install_Axway_Installer_VX.Y.Z.properties), except
InstallDir,InstallationLogicalName
Example
You can use any text editor or the Silent File Editor to modify variables in the silent file.
An example of changing the installation directory:
InstDir = C:\<install directory>\
InstDir.Type = String
InstDir2 = C:\<install directory>\Composer
InstDir2.default = <InstDir>/Composer
Using silent mode

To run the installer in silent mode, you need the following commands:
Windows:
l setup32.exe –s <the absolute path to the installer Silent File>
l setup64.exe –s <the absolute path to the installer Silent File>
The installer's silent file is located in <install directory>/SilentFile/<DirectoryDate>/ after
installation and is called Install_Axway_Installer_V<version>.properties.
The Silent File directory contains:
l Installer properties file (Install_Axway_Installer_V<version>.properties)
l Transfer CFT properties file (Install_Transfer_CFT_V<version>.properties)
l The com.axway.installer folder
You should always call the Axway_Installer silent file from the command line regardless of the
number of products you want to install. You can add or delete products from the silent installation if
necessary, as long as they exist in the Silent File. Open the Axway_Installer properties file and scroll
to the end. There are a number of IncludeFiles specifying the number of products included for an
installation. You must not modify anything else in this file except the InstallDir, the
InstallationLogicalName and the list of IncludeFiles.
Follow these recommendations concerning a silent installation:

2 Install
l You must use the absolute path to the silent file and not the relative one
l The command must point to the installer silent file and not the product silent file
l The product silent files installed in silent mode must be in the same directory as the installer
silent file
l The com.axway.installer folder/directory must be in the same directory as the silent files
Note When performing a silent installation, you must not use the "com.axway.installer" that
already exists in the installation package (that is, where the setup.sh/bat file resides).
Instead, you must copy this folder from the SilentFile directory and replace the existing one
originally in the installation package.
Install products silently in a directory with white spaces

In Windows, the installer supports the silent installation in a folder, for example (c:\Program Files),
with white spaces if:
l All products in the Silent File allow white spaces, regardless of the other products present in the
installation package (which are not listed in the Silent File)
The installer does not support installation in a folder with white spaces and the installation will stop
if:
l At least one of the products in the Silent File does not allow white spaces, regardless of the
other products present in the installation package (which are not listed in the Silent File)
Configure product in silent mode

To configure an installation in silent mode, you need the following commands:
Windows:
l configure32.exe –s <the absolute path to the installer Silent File>
l configure64.exe –s <the absolute path to the installer Silent File>
Silent File Editor

Use the Silent File Editor to modify variables in a silent file. It can be used from the command line or
the GUI.
The most common values that you replace when preparing a new installation using a silent file are
the InstallDir and CommonDir variables. The value of these fields is used to concatenate other paths
in the products silent file properties file.
Location
The Silent File Editor is in the installation directory in Tools/SilentFileEditor.
Note Copying the Silent File Editor from the installation package is not supported because it
uses binary files from the installer.

2 Install
Modifying a silent file using the command line

To modify a silent file using the command line, run:
l In Windows: SilentFileEditor.bat
The parameters for the Silent File Editor are:
l The path to the silent file that you want to modify
l Three arguments in this format:
o The first argument is the name of the variable that you want to modify (for example,
DB_ADMIN_PASSWORD). Each variable name given must exist in the silent file
o The second argument is the value that you want to assign to the variable given as the
first argument
o The third argument is –c if the value is to be encrypted first and then saved in the silent
file, or –u if the value does not need to be encrypted
You can have more than one group of arguments as shown in the examples below.
Example
SilentFileEditor.bat SilentFilePath varName1 value1 –c/-u varName2

value2 –c/-u … varNameN valueN –c/-u
Modifying a Silent File using the user interface
Starting the GUI

To start the Silent File Editor GUI, run SilentFileEditorGUI.bat or SilentFileEditorGUI.sh at
<installation directory>\Tools\SilentFileEditor.
Using the GUI

The GUI displays the list of variables and values in the silent file.
Use File > Open to open the silent file you want to edit.
From the Tools menu you can:
l Encrypt Selected: Encrypts the Values selected with the AES128 algorithm
l Undo Selected: Undoes the changes made on the current selection
l Undo all changes: Undoes all changes made on the current selection
l Replace: Finds a variable and replaces it with the value you select. Inside of the Replace
command there are other options:
l Replace all: Replaces all paths in all the variable values

2 Install
l Find next: Goes to the next value occurrence and if you click Replace it replaces the value
l Encrypt: Encrypts the value in the Replace Value with field
Once you have completed all the modifications, use File > Save to save the silent file, then File >
Exit to quit the Silent File Editor UI.
Install active/active - Windows

This section describes how to install active/active failover, as described in About Multi-node
architecture.
Note Transfer CFT supports all POSIX file systems.
Prerequisites
When installing a Transfer CFT multi-node architecture in Windows, the user performing the
installation must:
l Be a domain user who is part of the Administrators group.
l Be the same user for all machines.
l Have all rights (create/modify/delete) to the shared disk on all machines when Transfer CFT is
installed in a multi-host architecture.
Transfer CFT in multi-host architecture requires:
l A shared file system
l You must configure the system prior to the multi-node installation, and the shared disk should
be ready when you start the Copilot server. See Shared file system prerequisites on page 14 for
details.
See Applying a license key for license key information.
Overview
To perform an active/active installation of Transfer CFT in multi-node (HA):
l Install Transfer CFT using the Cluster installation architecture of the Installer and
enable the multi-node architecture.
o The first host installation (meaning the first node as defined in the Axway
Installer) sets the Shared directory, the <Transfer_CFT Shared> directory and
all of the Transfer CFT configurations.
o During each hosts installation (meaning additional nodes as defined in the
Axway Installer), you are prompted to specify the shared directory, and all
parameters from the first installation will be automatically loaded.

2 Install
l Transfer CFT binaries are installed on several hosts and runtime files are installed on a
shared file system.
o One or several hosts are active.
o All Transfer CFT runtime environments (Transfer CFT nodes) are running.
Note Transfer CFT binaries can be patched on each host one after the other without stopping the
Transfer CFT instance (all of the Transfer CFT nodes).
Install the cluster nodes

There are two general steps for installing a product in a cluster.
1. Install the first node in the cluster.
2. Install additional nodes in the cluster.
After installation, but before you can use the cluster installation, you must configure the cluster for
high-availability operations. The procedure for cluster configuration varies depending on the type of
platform on which the cluster is installed.


Shared Directory


2 Install
Shared directory
Integrate Transfer CFT in a Microsoft Cluster

Service (MSCS)
Prerequisites

License key
The Transfer CFT license key refers to a specific machine, and is based on the machine's hostname.
To allow Transfer CFT to start on both cluster nodes, you need one license key per node. Enter the
two license keys in the %CFTKEY% file located on the shared disk, one key per line.

following types of files used with Transfer CFT in a UNIX environment.
directory.

2 Install
application files.
application files.


system

OpenVMS RMS


2 Install
Using a shared file system

In a multi-node context, a shared file system allows multiple applications to access the same files at
the same time. Two typical shared file system implementations are NAS (network attached storage)
and SAN (storage area network). This section describes GPFS, NFSv4, AWS EFS, and CIFS as they
pertain to Transfer CFT multi-node installations.
Note In Transfer CFT, you can use any Portable Operating System Interface (POSIX) compliant
shared file system for transferable application files.
Using GPFS as a shared file system

GPFS, General Parallel File System, is the shared file system of choice for Transfer CFT. It provides
high-speed file access for Transfer CFT when executing in a multi-node architecture.
Use the default setting for GPFS usage

By default the shared file system is set to unknown, the value to use for GPFS. If you are uncertain as
to the file system setting for the Transfer CFT internal data files, execute the following command to
return to the default setting:
CFTUTIL uconfunset id=cft.multi_node.shared.filesystem.type
Using NFSv4 as a shared file system

The recommendations in this section apply to a Transfer CFT multi-node, multi-host architecture
based on an NFSv4 shared file system. To implement a Transfer CFT active/active architecture using
NFS, version 4 is mandatory. This is because NFSv4 can detect host failures (unlike NFSv3). With
host failure detections possible, Transfer CFT can restart another host's nodes when necessary.
To implement active/active Transfer CFT you must use NFSv4 for the Transfer CFT runtime directory,
which contains internal data such as the catalog, log, communication file, etc. Other versions of
NFS are not supported for the runtime directory. For file exchanges, you can use either NFSv4 or v3.
NFSv3 is not described in this document.
l Required NFSv4 mount options
l Mount options summary
l Synchronous / asynchronous option impact
l Tuning NFSv4 locking for node failover
l Troubleshoot an NFS lock daemon issue
Define NFS as the shared file system

Execute the following command to enable the Transfer CFT internal data files to reside on a NFSv4
file system.
Enter the nfs value in lower case:

2 Install
CFTUTIL uconfset id=cft.multi_node.shared.filesystem.type,

value=nfs
Required NFSv4 mount options
Define the NFS version

If version 4 is not your NFS subsystem's default, you must specify version 4 when defining the
mount options. Depending on your OS, use either the vers or nfsvers option.
Set the hard and nointr options

Mount NFSv4 using the hard and nointr options. The intr mount option should not be available
for NFSv4, but if you are in d oubt, you should explicitly specify the nointr option.
Define file locking

Because Transfer CFT uses POSIX file locking services to synchronize shared files, make sure that the
NFS clients report these locks to the NFS server. Depending on the NFS client, the c orresponding
option to tune may be called local_lock, llock, or nolock. Do not enable the local locking
option.
Set the cto option

NFS implements a weak data consistency called "Close To Open consistency" or cto. This means
that when a file is closed on a client, all modified data associated with the file is flushed from the
server. If your NFS clients allow this behavior, be certain that the cto option is set.
Mount options summary

The following table summarizes the recommended NFSv4 mount options. Note that depending on
the OS platform, only one of the three locking options should be available.
Correct option Incorrect option
vers=4 (or nfsvers=4) not specified or value <= 4
hard ( default) "soft" specified
nointr (not the default) "intr" specified
llock not specified "llock" specified

2 Install
lock ( default) "nolock" specified
local_lock=none (default) any other value specified
cto ( default) "nocto" specified
Synchronous versus asynchronous option

To improve performance, NFS clients and NFS servers can delay file write operations in order to
combine small file IOs into larger file IOs. You can enable this behavior on the NFS clients, NFS
servers, or on both, using the async option. The sync option disables this behavior.
Client
On the client side, use the mount command to specify the async/sync option.
Async
The NFS client treats the sync mount option differently than some other file systems. If neither
sync nor async is specified (or if async is specified), the NFS client delays sending application
writes to the server until any of the following events occur:
l Memory limitations force reclaiming of system memory resources.
l Transfer CFT explicitly flushes file data (PeSIT synchronization points, for example).
l Transfer CFT closes a file.
This means that under normal circumstances, data written by Transfer CFT may not immediately
appear on the server that hosts the file.
Sync
If the sync option is specified on a mount point, any system call that writes data to files on that
mount point causes that data to be flushed to the server before the system call returns control to
Transfer CFT. This provides greater data cache coherence among clients, but at a significant cost to
performance.
Server
On the server side, use the exports command to specify the async/sync option (NFS server
export table).

2 Install
Async
The async option allows the NFS server to violate the NFS protocol and reply to requests before
any changes made by that request have been committed to stable storage (the disk drive, for
example), even if the client is set to sync. This option usually improves performance, however d ata
may be lost or corrupted in the case of an unclean server restart, such as an NFS server crash.
This possible data corruption is not detectable at the time of occurrence, because the async option
instructs the server to lie to the client, telling the client that all data was written to stable storage
(regardless of the protocol used).
Sync
Enables replies to requests only after the changes have been committed to stable storage.
Note For more information on these options, refer to NFS mount and export options in the
UNIX man pages (for example, here).
Synchronous / asynchronous option impact

Client Server Internal data Transferable Performance
data
Sync Sync 1 1 Low
Sync Async 2 ( secure the NFS server) 2 ( secure the Medium

NFS server)
Async Sync 1 ( if cft.server.catalog. 1 ( when using Medium - high

sync.enable=Yes) sync points)
Async Async 3 3 High
Legend:
l 1 = Secure
l 2 = Fairly secure
l 3 = Not secure
l Internal data = Transfer CFT runtime files, such as the catalog
l Transferable data = Files exchanged using Transfer CFT
Tuning NFSv4 locking for node failover

The NFSv4 locking lease period affects the Transfer CFT delay required to detect node failovers. The
default value for this parameter is typically 90 seconds. On systems where this parameter is tunable,
configuring a shorter value can significantly reduce Transfer CFT node failovers.

2 Install
Troubleshoot an NFS lock daemon issue with no error message

When transferring files that are located in a Network File System, an NFS locking issue (lockd) may
occur if the correct port is not open on the firewall.
Symptom
l Flow transfers hang in the phase T and phasestep C, with a timeout but no error message.
Remedy
l Check that the correct port for the lockd service is open on the firewall (default=4045).
Using AWS EFS as a shared file system

based on an Amazon Web Services (AWS) Elastic File System (EFS) shared file system.
When using AWS EFS, you cannot set the server options; only the client is configurable.
This system is based on NFSv4. For more information on NFSv4, please see Using NFSv4 as a shared
file system.
This shared file system has features that impact performance, as compared to a traditional NFS:
l Distributed systems replicating data
l Processing does not continue until all data is replicated
Using CIFS as a shared file system

Windows only
CIFS, Common Internet File System, shares files across corporate intranets and the Internet, and is
available as a shared file system when running Transfer CFT in a Windows environment.
Install active/passive - Windows

This section describes how to install an active/passive architecture, as described in About Multi-node
architecture.
Note Transfer CFT supports all POSIX file systems. Active/passive shared disks must be POSIX
compliant!
A cluster installation of Transfer CFT without multi-node is an active/passive installation as described
below:
l Install Transfer CFT using the Cluster installation architecture of the Installer and disable the
multi-node architecture.

2 Install
o The first host installation
o Additional hosts installation
l Transfer CFT binaries are installed on several hosts and runtime files are installed on a shared file
system.
l You must configure the cluster after installation but before you can use the cluster. The
procedure for cluster configuration varies depending on the platform on which the cluster is
installed.
o Only one host is active
o Only one Transfer CFT runtime environment is running on the active host

Shared Directory
Prerequisites
Transfer CFT in multi-host architecture requires:
l A shared file system
l You must configure the system prior to the multi-node installation, and the shared disk should
be ready when you start the Copilot server. See Shared file system prerequisites on page 14 for
details.
See Applying a license key for license key information.
Install
Download and unzip the Transfer CFT install package.
Run the installer. In the Cluster options, select:
o Cluster - Installs Transfer CFT on several machines. Select this option if you want to install
Transfer CFT in active/passive mode.
However, do not enable the multi-node option, as this creates an active/active Transfer
CFT installation. Otherwise, the installation is active/passive.

2 Install


Shared Directory

Shared directory
Integrate Transfer CFT in a Microsoft Cluster

Service (MSCS)
Prerequisites

2 Install


following types of files used with Transfer CFT in a UNIX environment.
directory.
application files.
application files.


system


2 Install

system
OpenVMS RMS

Using a shared file system

In a multi-node context, a shared file system allows multiple applications to access the same files at
the same time. Two typical shared file system implementations are NAS (network attached storage)
and SAN (storage area network). This section describes GPFS, NFSv4, AWS EFS, and CIFS as they
pertain to Transfer CFT multi-node installations.
Note In Transfer CFT, you can use any Portable Operating System Interface (POSIX) compliant
shared file system for transferable application files.
Using GPFS as a shared file system

GPFS, General Parallel File System, is the shared file system of choice for Transfer CFT. It provides
high-speed file access for Transfer CFT when executing in a multi-node architecture.
Use the default setting for GPFS usage

By default the shared file system is set to unknown, the value to use for GPFS. If you are uncertain as
to the file system setting for the Transfer CFT internal data files, execute the following command to
return to the default setting:
CFTUTIL uconfunset id=cft.multi_node.shared.filesystem.type
Using NFSv4 as a shared file system

based on an NFSv4 shared file system. To implement a Transfer CFT active/active architecture using
NFS, version 4 is mandatory. This is because NFSv4 can detect host failures (unlike NFSv3). With
host failure detections possible, Transfer CFT can restart another host's nodes when necessary.

2 Install
To implement active/active Transfer CFT you must use NFSv4 for the Transfer CFT runtime directory,
which contains internal data such as the catalog, log, communication file, etc. Other versions of
NFS are not supported for the runtime directory. For file exchanges, you can use either NFSv4 or v3.
NFSv3 is not described in this document.
l Required NFSv4 mount options
l Mount options summary
l Synchronous / asynchronous option impact
l Tuning NFSv4 locking for node failover
l Troubleshoot an NFS lock daemon issue
Define NFS as the shared file system

Execute the following command to enable the Transfer CFT internal data files to reside on a NFSv4
file system.
Enter the nfs value in lower case:
CFTUTIL uconfset id=cft.multi_node.shared.filesystem.type,

value=nfs
Required NFSv4 mount options
Define the NFS version

If version 4 is not your NFS subsystem's default, you must specify version 4 when defining the
mount options. Depending on your OS, use either the vers or nfsvers option.
Set the hard and nointr options

Mount NFSv4 using the hard and nointr options. The intr mount option should not be available
for NFSv4, but if you are in d oubt, you should explicitly specify the nointr option.
Define file locking

Because Transfer CFT uses POSIX file locking services to synchronize shared files, make sure that the
NFS clients report these locks to the NFS server. Depending on the NFS client, the c orresponding
option to tune may be called local_lock, llock, or nolock. Do not enable the local locking
option.
Set the cto option

NFS implements a weak data consistency called "Close To Open consistency" or cto. This means
that when a file is closed on a client, all modified data associated with the file is flushed from the
server. If your NFS clients allow this behavior, be certain that the cto option is set.

2 Install
Mount options summary

The following table summarizes the recommended NFSv4 mount options. Note that depending on
the OS platform, only one of the three locking options should be available.
vers=4 (or nfsvers=4) not specified or value <= 4
hard ( default) "soft" specified
nointr (not the default) "intr" specified
llock not specified "llock" specified
lock ( default) "nolock" specified
local_lock=none (default) any other value specified
cto ( default) "nocto" specified
Synchronous versus asynchronous option

To improve performance, NFS clients and NFS servers can delay file write operations in order to
combine small file IOs into larger file IOs. You can enable this behavior on the NFS clients, NFS
servers, or on both, using the async option. The sync option disables this behavior.
Client
On the client side, use the mount command to specify the async/sync option.
Async
The NFS client treats the sync mount option differently than some other file systems. If neither
sync nor async is specified (or if async is specified), the NFS client delays sending application
writes to the server until any of the following events occur:
l Memory limitations force reclaiming of system memory resources.
l Transfer CFT explicitly flushes file data (PeSIT synchronization points, for example).
l Transfer CFT closes a file.
This means that under normal circumstances, data written by Transfer CFT may not immediately
appear on the server that hosts the file.

2 Install
Sync
If the sync option is specified on a mount point, any system call that writes data to files on that
mount point causes that data to be flushed to the server before the system call returns control to
Transfer CFT. This provides greater data cache coherence among clients, but at a significant cost to
performance.
Server
On the server side, use the exports command to specify the async/sync option (NFS server
export table).
Async
The async option allows the NFS server to violate the NFS protocol and reply to requests before
any changes made by that request have been committed to stable storage (the disk drive, for
example), even if the client is set to sync. This option usually improves performance, however d ata
may be lost or corrupted in the case of an unclean server restart, such as an NFS server crash.
This possible data corruption is not detectable at the time of occurrence, because the async option
instructs the server to lie to the client, telling the client that all data was written to stable storage
(regardless of the protocol used).
Sync
Enables replies to requests only after the changes have been committed to stable storage.
Note For more information on these options, refer to NFS mount and export options in the
UNIX man pages (for example, here).
Synchronous / asynchronous option impact

Client Server Internal data Transferable Performance
data
Sync Sync 1 1 Low
Sync Async 2 ( secure the NFS server) 2 ( secure the Medium

NFS server)
Async Sync 1 ( if cft.server.catalog. 1 ( when using Medium - high

sync.enable=Yes) sync points)
Async Async 3 3 High
Legend:

2 Install
l 1 = Secure
l 2 = Fairly secure
l 3 = Not secure
l Internal data = Transfer CFT runtime files, such as the catalog
l Transferable data = Files exchanged using Transfer CFT
Tuning NFSv4 locking for node failover

The NFSv4 locking lease period affects the Transfer CFT delay required to detect node failovers. The
default value for this parameter is typically 90 seconds. On systems where this parameter is tunable,
configuring a shorter value can significantly reduce Transfer CFT node failovers.
Troubleshoot an NFS lock daemon issue with no error message

When transferring files that are located in a Network File System, an NFS locking issue (lockd) may
occur if the correct port is not open on the firewall.
Symptom
l Flow transfers hang in the phase T and phasestep C, with a timeout but no error message.
Remedy
l Check that the correct port for the lockd service is open on the firewall (default=4045).
Using AWS EFS as a shared file system

based on an Amazon Web Services (AWS) Elastic File System (EFS) shared file system.
When using AWS EFS, you cannot set the server options; only the client is configurable.
This system is based on NFSv4. For more information on NFSv4, please see Using NFSv4 as a shared
file system.
This shared file system has features that impact performance, as compared to a traditional NFS:
l Distributed systems replicating data
l Processing does not continue until all data is replicated
Using CIFS as a shared file system

Windows only
CIFS, Common Internet File System, shares files across corporate intranets and the Internet, and is
available as a shared file system when running Transfer CFT in a Windows environment.

2 Install
Installer functions
Installer functions
This section describes functions you can perform with the installer.
Display command
The display command lists information about all installed products. The command is named
display.bat on Windows and display.sh on UNIX and Linux. Run it from the root installation
directory.
When run without parameters, the command lists all installed products and versions and all applied
service packs.
Use the name parameter to display the installation history of a single product. For example:
display -n <product name>
Install product
To start the installer to install a product:
Locate and run the setup file in the root folder of the installation package you downloaded from the
Axway support site and uncompressed or unzipped.
GUI mode
l setup32.exe or setup64.exe
Console mode
l setup32.exe -m console or setup64.exe -m console
setup32.exe is a 32-bit build executable and will run on a 64-bit platform provided that the
compatibility layer has been installed.
Windows installations
The same user that did the initial installation (or at least the same type of user) must start the
installer.
Services modification
Some products support an installation in service mode with a user other than the default (Local
System Account).

2 Install
If the domain field is not shown in the products service configuration dialog, then it must be
introduced in the username field, using this format:
<domain>\<username>
If it is a local user (a user that was created on the local machine) then the <domain> field can be .
or the <hostname>.
Example
Local user: user1
.\user1
<hostname>\user1
Network user: user2
<domain_name>\user2
Configure product
This section describes running the installer in configure mode to change a product's configuration.
The following describes running the installer in configure mode.
GUI mode
l In the Windows Start menu, select Axway Software > Axway [installation name] >

Configure
Console mode
l l configure32.exe –m console
l configure64.exe –m console
Note If you do not want to use either the GUI or console modes to configure your installation,
refer to the Silent mode.
About host name

Host name corresponds to the object assigned to a physical server. In the installer, host name is
required for the following reasons:
l In a license key page, to validate that the entered key matches the host name. In this case, enter
only the host name (without the domain name) and make sure not to confuse Hostname with
Logical Server Name.
l In a page where you configure which network interface the product is going to listen for an
incoming connection. In this case, enter one of the following values:
o Host name
o The fully qualified name (host name and domain name)
o IP address of the machine

2 Install
o Specific string (0.0.0.0 or *) indicating that you want the product to listen on all
network interfaces if your machine has more than one
o Logical host name or IP address if you are doing an installation on a machine that is part
of a cluster
l In a page where you configure how your product is going to connect to another product. In
this case, it is strongly recommended to use either the fully qualified name or the IP address of
the remote machine. If the remote machine you are connecting to is a cluster, then use the
logical, fully qualified cluster host name or IP address.
Using a temporary directory

The installer needs a temporary directory when it starts to unzip and prepare the environment it
requires for product or update installation. The temporary directory it uses is the first %TMPDIR%,
%TMP% or %TEMP% environment variable that is not null. It is very important that the value of the
variable does not contain any spaces. If it does, a NullPointerException java error occurs.
You can force the use of another temporary directory by setting the following environment variable,
TEMPORARY_DIR.
If you do this make sure the temporary directory has:
l Enough disk space
l Read/write access for starting the installer
Installation modes
You can use the following installer installation modes.
l GUI mode is supported on Windows, UNIX and Linux. However, to use on UNIX platforms, the
installer requires an X-Window environment. To use an X-Window distributed environment, you
must export the DISPLAY environment variable: export DISPLAY=myhost.mydomain:0.0
l Console mode displays a series of prompts requiring user responses or actions.
l Silent mode enables you to perform an installation or configuration in a non-interactive mode.
You do not have to enter any parameters in the GUI or console.
Installer functions
The installer command files are for invoking installer functions in GUI or console mode.
Before installing, install is the only available function, invoked with the setup file in the root
directory of the installation package.
After installing, the configure, update and uninstall functions are available. The scripts for those
functions are in the root installation directory.

2 Install
Function Mode Windows
Install GUI setup32.exe

setup64.exe
Console setup32 –m console
setup64 –m console
Configure GUI configure32.exe

configure64.exe
Console configure32.exe –m console
configure64.exe –m console
Update GUI update32.exe

update64.exe
Console update32 –m console
update64 –m console
Uninstall GUI uninstall32.exe

uninstall64.exe
Console uninstall32.exe –m console
uninstall64.exe –m console
The configure function lets you change settings that were applied during installation.
The update function lets you apply or remove service packs and patches.
After installing the following functions are available:
l Install product
l Configure product
l Update product and Remove updates
l Uninstall product
l Transfer installation packages on remote machines
JRE customization
To avoid compatibility issues for a product based on Java, Axway provides the correct JRE, which is
installed during the product installation. However, a lightweight installer does not have a JRE. You
start the installer with the JRE already installed on your machine. In other words, the installer runs
with an external rather than internal JRE.
The advantages are that it allows you more flexibility and saves you on disk space storage.
The infrastructure dependent artifact of the installer is separated into two artifacts (tools and java).

2 Install
All Axway products can use an external JRE. This is specifically useful for C coded products as
downloading the JREs is no longer mandatory as part of an installation kit.
Installer-dependent deliverables
The installer-dependent artifacts are split in two parts (tools and java), now that using a standard
JRE is optional.
The names of the two artifacts have not changed from the previous ones except they have a -tools
and -java suffix:
l The Axway_Installer_VG.M.m_<platform>-tools artifact contains the necessary tools required
by the installer which are platform specific and are still mandatory in the installation kit.
l The Axway_Installer_VG.M.m_<platform>-java artifact contains the standard JREs delivered by
the installer which are platform specific and are now optional.
Run the installer using an external JRE

To run the installer with an external JRE:
l Set the AXWAY_JAVA_HOME environment variable or JAVA_HOME environment variable.
l The installer starts in the following order of precedence with the JRE specified in the:
l Installation kit in the Java/<platform> folder
l AXWAY_JAVA_HOME
l JAVA_HOME
The environment variables need to point to the root of the JRE installation. The Java instance will
run from <ENV_VAR_PATH>/bin/java.
Run a product using an external JRE

This section describes running products after installing in various modes.
Normal installation
When you perform a clean installation with the installer using an external JRE, all installed products
are configured to use the external JRE. This also means the installer cannot install products that do
not support the external JRE.
When you run the installer with either an internal or external JRE for the purpose of managing an
existing installation (adding additional features or products), all the products including the newly
installed ones will use the JRE configured for the existing installation and not the JRE configured to
run with the installer.
When you run the installer in configure mode, it does not apply any changes on the type of internal
JRE used. If the installation is configured to use an external JRE, all products are reconfigured to use
the new paths specified in the environment variables.

2 Install
Caution To set the JRE, the installer uses the path specified in the environment variable at install
time, not the environment variable itself. This means that any manual changes you make
to the environment variables will not be taken into account. If you want to change the
external JRE used by an installation you need to first change the value of the
environment variable and then run installer in Configure mode on that installation.
Note that some products do not currently support reconfiguring the Java path. It means that for
these products, the Java path cannot be modified using the installer and, if necessary, will have to
be done manually.
Caution Do not modify or delete the paths specified in the environment variables used to set the
external JRE after installation. If you make any changes to these paths, it will directly
affect the functioning of all the installations configured to use them. You should handle
any modifications to these environment variables and Java paths with extreme caution.
Silent installation
The parameters from silent files used for specifying the JRE to use will always be overwritten
depending on the context of the installation:
For example if you have silent files made from a package which contained Java and a silent
installation that is generated with a package without the embedded Java:
l The installer re-computes the Java paths required by the products, and transparently ignores
the corresponding settings in the silent file (if any)
l The reverse case is handled in the same manner

Post installation
3
After installing Transfer CFT, but before starting Transfer CFT and the Copilot server, you may need
to perform the following tasks:
l Perform an update
l Create a basic configuration
Otherwise you can go to:
l Start the Transfer CFT Copilot server on page 63
l Start Transfer CFT on page 63
For information on user rights, refer to the topic Defining user rights UNIX in the Transfer CFT User
Guide.
Installed directories
(missing or bad snippet)
Perform an update
If you need to apply service packs or patches, refer to Update Transfer CFT.
If you have already started Transfer CFT or Copilot, stop these servers prior to performing an update.
Create a basic configuration

This section describes how to create a basic Transfer CFT configuration if you did not do so during
the installation process. If you started Transfer CFT or Copilot, stop these servers before modifying
the configuration.
Update the profile

To add environment variables to your Transfer CFT profile edit the following script:
l Windows: <CFTDIRRUNTIME>\profile.bat

3 Post installation
UCONF
To determine the Transfer CFT variable values list the values using the command:
CFTUTIL listuconf
To change or update a value, start the Transfer CFT profile and make modifications using either the
Transfer CFT Copilot UI or command line UCONF tools.
For example, to change the user interface port:
CFTUTIL uconfset id=copilot.general.serverport,value=1766
Configuration
Before you can start Transfer CFT for the first time, Transfer CFT must have a basic configuration.
Typically this is created during installation or migration.
License key
If you did not enter the license key during installation, you can enter it post installation in a cft.key
file in: <CFTDIRRUNTIME>/conf/
You can enter a single key or a list of keys in this file. In the configuration default file, the variable
<$CFTKEY> represents the cft.key file.
Transfer CFT internal datafile and configuration

Check the values, especially the key value, hostname, and port for TCP, in the following file:
l Windows and UNIX: <CFTRUNTIME>/conf/cft-tcp.conf
Start the Transfer CFT profile and, to create the Transfer CFT internal datafile and update the basic
configuration, execute:
cftinit cft-tcp.conf
To update the configuration at a later date, execute:
cftupdate cft-tcp.conf

3 Post installation
User interface configuration

To view the Copilot user interface c onfiguration, execute:
CFTUTIL LISTUCONF id=copilot*
To change this configuration, you update the hostname and listening p ort for Transfer CFT UI using
CFTUTIL uconfset.
Example
CFTUTIL uconfset id=copilot.general.serverhost, value="127.0.0.1"

CFTUTIL uconfset id=copilot.general.serverport, value="7000"
Refer to the Transfer CFT User Guide for details.
Configuration for Service Mode

This option is only available on Windows systems and must be selected during the installation
process configuration.
Start the Transfer CFT Copilot server

If you have implemented Central Governance, starting Copilot launches the registration process. For
more information, see the topic Registering with Central Governance in the Transfer CFT User Guide
Windows
1. Change d irectory to the runtime.

2. Execute profile.bat.
3. To start the Copilot server, enter: copstart
4. To check the Copilot status, enter: copstatus -v
Start Transfer CFT

If you have implemented Central Governance, you can start and stop Transfer CFT via the Central
Unified Flow Management user interface. Otherwise perform the following command from the
Transfer CFT runtime directory.
Enter:
cft start

Update, upgrade or migrate
4
Start here: Upgrade, update, and migration
This chapter is designed to assist administrators or users who are tasked with updating Transfer CFT,
or upgrading or migrating from an existing Transfer CFT version to Transfer CFT 3.3.2.
Updates versus upgrade or migrate
About updates
An update brings Transfer CFT up-to-date with a patch or service pack offering fixes and minor
enhancements. For example, you can update a Transfer CFT 3.1.3 SP3 to Transfer CFT 3.1.3 SP8.
See Updating Transfer CFT.
About upgrades
An upgrade is the process of updating to a newer, enhanced version of the software. For example,
you can update a Transfer CFT 3.1.3 to Transfer CFT 3.2.4. See Upgrading Transfer CFT.
Axway provides Upgrade Packs for products to simplify the process of updating from a previous
version. When upgrading, you run the Axway Installer to apply the Upgrade Pack using a procedure
that is similar to updating an Axway product. For more information, go to Upgrading Transfer CFT or
Upgrading Transfer CFT in multi-node architecture.
This mode has the following advantages ( as compared to a migration):
l Allows you to update in the same location
l You can perform this automatically using the Installer, and you can revert to previous state if
needed
l Scripts and APIs remain intact and only require a recompilation for the APIs
This mode has the following restriction:
l You must uninstall the upgrade pack if you need to rollback.
l You cannot upgrade on versions older than version 2.6.x.

4 Update, upgrade or migrate
About migrations
A migration means that an initial Transfer CFT is installed in a directory that is not removed or
overwritten by the procedure. You can use the OS-appropriate installation kit to install the Transfer
CFT 3.3.2 in a new directory, and select the installation option to migrate the existing configuration
to this new version. You are only required to provide the p ath of the Transfer CFT (n-1) version to
retrieve this old configuration.
The Transfer CFT versions that are available to migrate include 2.3.2, 2.4, 2.5, 2.6, 2.7, 3.0.1,
3.1.2x, and 3.2.x.
Note If you are migrating from a previous version of Transfer CFT, be sure to check the Release
Notes for new features as well as deprecated features and supported platforms per release.
About install and automatic import

You can use an automatic installation procedure to migrate from your current version of Transfer
CFT to Transfer CFT 3.3.2. This auto-migration procedure occurs when you perform the Transfer
CFT 3.3.2 installation.
This mode has the following advantages:
l The new installation occurs in a new location, and existing configuration elements and data can
be automatically imported
l You can install and auto import from versions older than version 2.6.x.
l You can choose to use either of the versions, if needed, in case of an issue with one of the
installations
Note Configuration and data, such as the catalog, are in two separate locations and data are not
shared.
This mode has the following restriction:
l You must copy scripts and APIs from the previous version to the new installation.
About standard migrations

A standard migration procedure, also used for migrating your existing Transfer CFT to Transfer CFT
3.3.2, is available.
The general procedure for migrating from a previous version of Transfer CFT to Transfer CFT 3.3.2 is
as follows:
1. Export existing information from the previous version. Details vary depending on the
existing Transfer CFT version.
2. Import the exported information into Transfer CFT 3.3.2.
This mode has the following advantages:
l Because this migration is not automated, you can customize as needed.
l You can perform a standard migration to move from versions older than version 2.6.x.

Update or upgrade using Central Governance

Central Governance simplifies the management of Transfer CFT and provides identity and access
management, certificate security services, monitoring, alerting, and web dashboard services. If you
are using Transfer CFT 3.3.2 with Central Governance, you can use the information in Activate
Central Unified Flow Management connectivity to configure and register with Central Governance.
Central governance allows you to update (to the latest Transfer CFT Service Pack or patch) or
upgrade Transfer CFT (as of Transfer CFT 3.2.4 with the latest SP to the new Transfer CFT version).
However, you cannot perform a Transfer CFT migration using Central Governance.
Note You cannot perform an upgrade on the following platforms: z/OS or IBM i.
Important information
Important information before performing an upgrade or install auto-import procedure:
l You must update your Transfer CFT to the most recent service pack version.
l Upgrade the Axway Installer to 4.10, if you are not at this version or higher, prior to upgrading
your Transfer CFT 3.3.2.
l If needed, you can uninstall an Upgrade Pack. Doing so rolls back to the previous version
before the upgrade, but all transfers and configuration modifications that were performed since
the upgrade are lost.
l Backup Transfer CFT before beginning an upgrade or migration procedure.
l Before beginning the upgrade or migration procedure stop the existing version of Transfer CFT
and the GUI server.
More information
If you encounter issues when migrating Transfer CFT, contact Axway Support at
https://support.axway.com.
Determine the installer and product version

You should determine the product and Installer version and service pack level prior to updating or
upgrading. You can use the following procedure on any version of the Axway Installer. For more
information on the installer, see Installer functions on page 55 and JRE customization on page 58.
Start the Axway Installer. The command depends on the Installer version and your OS, as follows:
l Versions lower than 4.5.x:
o setupwin32.exe update
l Version 4.5.x or higher:
o update32/64.exe

Accept the license and click Next to continue. In the Product list, check the:
l Axway Installer version and the most recently installed SP level
l Transfer CFT version and the most recently installed SP level
Check product details

The display command lists information about all installed products.
l Run the command from the root installation directory.
l When you run this command without parameters, the command lists all installed products and
versions, and all applied service packs.
Use the name parameter to display the installation history of a single product.
display.bat
Windows Application Experience recommendation

The "Application Experience" service should be enabled when using Transfer CFT. Otherwise you
may encounter issues in accessing files when installing/upgrading the product.
Before beginning the upgrade or update procedure:
l You require the product and Installer version number and SP level in order to choose the
appropriate procedure. See the section Determine the Installer and product version.
l Download the Transfer CFT Upgrade Pack, available on Sphere at support.axway.com. The
Transfer CFT Upgrade Pack name has the general format Transfer_CFT_3.y.z_UP**-<from
version 2.6 through 3.2.2>_<OS>_BN<build_number>.zip, where ** is the UP
number. (You should not unzip the .zip file.)
Stop the Transfer CFT server and the Transfer CFT UI server, by entering:
o cft stop
o copstop -f
l Determine your Axway installer and product versions. The version dictates which of the
following Transfer CFT upgrade procedures is correct for you.
Note Windows: When upgrading, the same type of user that did the initial installation must
start the installer.

Update Transfer CFT

This section describes how to update Transfer CFT with a patch or service pack. You can manually
perform the operation or use Central Governance.
Download the update file

Download product updates from the Axway support website to the machine you where you want to
perform the update. Please note that the update file is a zip file. Do not unzip this file.
Tip To avoid possible issues if you decide to uninstall a service pack, it is recommended that
you install Transfer CFT 3.2.4 SP1 before installing SP2 or higher.
Check product details

To check the version, or product details prior to updating, use the display.bat command.
Note Prior to beginning the update, see the section Determine the installer and product versions.
Example 1
Use the display command to retrieve the name of the update, as displayed in red below:
display.bat -n Transfer_CFT
Transfer_CFT V3.2.4 SP1
Composite: Transfer_CFT_3.2.4_SP1
Example 2
Use this command to retrieve the name to uninstall (use the appropriate version, update64.exe or
update32.exe depending on your system):
update64.exe -u Transfer_CFT_3.2.4_SP1
Impacted directories when updating a product

When you install a service pack, the contents of the home directory are updated, but the runtime
directory remains untouched. This is so that your customizations, such as APIs, are not overwritten.
Use Central Governance for updates

You can easily perform Transfer CFT updates using Central Governance as of Transfer CFT 3.1.3.
Refer to the Central Governance documentation for details.

Limitations:
l You cannot remove SP or patches via the Central Governance interface.
l You cannot update Transfer CFTs installed in multi-node/multi-hosts from Central Governance.
Windows users
If you install a service pack or patch for the installer, make sure all Windows services created by the
installer are stopped.
The same user that did the initial installation (or at least the same type of user) must start the update
procedure. Additionally, if you install a service pack or patch for the installer, make sure all Windows
services created by the installer are stopped.
System Account).
<domain>\<username>
or the <hostname>.
Example
Local user: user1

.\user1
<hostname>\user1
Network user: user2
<domain_name>\user2
Change the backup folder

You can change the backup folder during the update. However, if the backup directory is changed,
you must copy all the files in the previous backup folder to the new location, and keep the product
directories structure. For example, the backup directory could have this format:
l BACKUP_DIR
l synInstall
l synPatch
l product.properties

l database.properties
l 001
The command UpdatesBackupDirectory changes the default update directory for all Axway products
in the installation. When the default update directory is over written, be careful not to delete it or
you cannot restore the installer to its previous state.
You can change the backup folder in two ways:
l From command line: UpdatesBackupDirectory <valid backup path>
l In the installer property file (Install_Axway_Installer_V4.5.2.properties), in the configuration
directory of your home installation.
Install patches and service packs

Stop Transfer CFT prior to installing a service pack or patch.
Update in silent mode

Use the following command to update Transfer CFT in silent mode:
update.exe -i <update_name>
Use this command to install a service pack in silent mode:
update.exe -i Transfer_CFT_3.2.4-SP1_win-x86-64.zip
Update in console mode

From the installation root directory, launch the installer in update mode:
l 32-bit executable: update32.exe –m
l 64-bit executable: update64.exe –m
Update in GUI mode

1. Run the installer in update mode. In Windows Start menu, select Axway Software > Axway
<InstallationName> > Update
2. Manage your updates. In the Updates Management page you have the following possibilities:
l Select a directory: Select the directory or zip archive file containing all the updates you
want to install.
l Select file: Select the update file you want to install. The file can be a .jar file or a zip
archive of .jar files.

3. The installer accepts the .zip file format containing the Service Packs to apply to more than one
product in the same installation package.
Information: Click to open the readme file.
4. Click Next to continue.
5. Review the updates you want to install.
6. To apply the update, click Update.
7. A warning message appears. Click Yes to continue.
8. After the updates are installed, click Next to view the summary.
9. Review the summary and click OK to exit the installer.
10. View log file. The updates installation is tracked in the updates.log file, located in your home
directory.
Uninstall patches and service packs

This section describes uninstalling a patch or service pack. You can uninstall updates in GUI or
console mode, depending on your operating system.
Remove updates in silent mode

Use the following command to uninstall a patch or SP in silent mode:
update.exe -u <update-name>
Use this command to uninstall a service pack in silent mode:
update.exe -u Transfer_CFT_3.2.4-SP1_win-x86-64.zip
Remove updates in console mode

For Windows environment:
1. From the installation root directory, launch the installer in appropriate update mode:
l update32.exe –m gui
l update64.exe –m gui
2. Follow the steps for uninstalling an update.
Remove updates in GUI mode

1. Run the installer in update mode. In the Windows Start menu, select Axway Software >
Axway <InstallationName> > Update

2. On the Updates Management page, Select the update you want to uninstall and click Remove.
The update changes from blue when first selected to gray.
4. Review the updates you want to uninstall. To remove the update, click Update.
5. After the updates have been uninstalled, click Next to view the summary. It displays the list of
updates that were removed.
Install patches and service packs in a multi-

node, multi-host environment
This section describes the procedure to apply a patch or service pack on a multi-node architecture
based on N hosts. You update a Transfer CFT multi-node architecture with multi-hosts using the
same procedure as for a patch or service pack, one host at a time.
Note Transfer CFT clusters can still run while performing an update.
1. Connect to the first host.
2. Stop all nodes running on this host by running the command: copstop
Copilot services are stopped, and local nodes are automatically re-started on the other hosts.
3. Check that the nodes are re-started by using the command: CFTUTIL listnode
4. Install the patch or the service pack as usual using the Axway Installer.
5. Start Copilot services.
6. Connect to the next host and repeat the procedure starting as of Step 2 (above).

Upgrade Transfer CFT

This section explains how to upgrade an existing Transfer CFT from versions 2.6 through 3.2.4 to
Transfer CFT 3.3.2. It begins by detailing the prerequisites for a standalone (non multi-node)
upgrade.
For details on upgrading a multi-node installation, see Upgrade a Transfer CFT multi-node
installation on page 86.
About upgrades
All passwords stored in the UCONF dictionary, or in the the Transfer CFT databases (for example,
CFTPART, CFTPARM) are cyphered using the key generated at installation. If you are performing an
upgrade, all passwords are cyphered using a hard-coded key. We recommend that you generate an
encryption key.
Transfer CFT 3.1.3 introduced the CUP, Composite Upgrade Package, feature. This functionality
enables you to upgrade both the installer and the product simultaneously.
Note See silent mode for detailed information on using the silent installation method.
Note When upgrading, the same type of user that did the initial installation must start the
installer.
Before you start

Before beginning the upgrade procedure:
appropriate procedure. See the section Determine the Installer and product version.
l Download the Transfer CFT Upgrade Pack, available at support.axway.com.
l Stop the Transfer CFT server and the Transfer CFT UI server, by entering:
o cft stop
o copstop -f
Windows Application Experience recommendation

You should enable the "Application Experience" service when using Transfer CFT. Otherwise you
may encounter issues in accessing files when installing/upgrading the product.

Use Central Governance to upgrade Transfer

CFT
You can perform Transfer CFT upgrades using Central Governance. However, from the Central
Governance interface you cannot remove service packs or patches, and can only upgrade Transfer
CFT as of Transfer CFT 3.1.3 with last service pack (to the latest version). You cannot perform a
Transfer CFT migration via Central Governance.
Please refer to the Central Governance documentation for details.

Upgrade Transfer CFT 2.6.4 to 3.3.2

Preconditions: Minimum versions for this procedure
This upgrade requires that your current installation is at least at the version levels listed below. Read
the Before you start p rior to beginning this procedure.
l Transfer CFT version: 2.6.4_SP7
l Axway Installer version: 4.3.1_SP2
l Embedded JRE version: 1.5.0_15
Note Remember to update the product key between versions (after completing the upgrade).
Step 1: Upgrade to Axway Installer 4.4.0 SP8 or the latest SP
Run the Axway Installer in update mode. Here it is shown in the default installation directory.
1. Start the Axway Synchrony Installer in update mode, shown here in the default installation
directory:
C:\Axway\Synchrony\setupWIN32.exe update
2. Apply the Synchrony_Installer_4.4.0_UP7-from-4.3.1_win-x86-64_BN16272.jar.
3. Start the Axway Synchrony Installer in update mode.
setupWIN32.exe update
4. Apply the Synchrony_Installer_4.4.0_SP8_allOS_BN25804.jar.
Step 2: Upgrade to JRE 160
Use the Axway JREUpdateTool to upgrade to JRE 1.6. This Axway tool is available on the Axway
Support site.
1. Unzip the JREUpdateTool_4.4.0_Utility_*****_BN1205240348.zip.
Where ***** represents the platform
Example: JREUpdateTool_4.4.0_Utility_win-x86-64_BN1205240348.zip
2. Upgrade to Java 1.6 using the appropriate command:
<JRETOOLS_DIRECTORY_WITHOUT_BLANKS>\updatejre.bat C:\Axway\Synchrony\
Step 3: Upgrade to Axway Installer 4.5.0 SP4 or the latest SP
Run the Axway Installer in update mode.
1. Start the Axway Synchrony Installer in updated mode:
2. Apply the Synchrony_Installer_4.5.0_UP1-from-4.4.0-4.4.1_allOS_BN1204251050.jar.
3. Start the Axway Synchrony Installer.

Note The program commands change in this step!

Windows: update32.exe o r update64.exe
4. Apply the Axway_Installer_4.5.0_SP4_allOS_BN22715.jar.
Step 4: Upgrade to JRE 160 update 37 using the JREUpdateTool
Use the Axway JREUpdateTool to update the JRE.
1. Unzip the JREUpdateTool_4.5.0_Utility_*****_BN1211090726.zip
Example: JREUpdateTool_4.5.0_Utility_win-x86-64_BN1211090726.zip
Step 5: Upgrade to Axway Installer 4.8.0
1. Start the Axway Installer.
update32.exe o r update64.exe
2. Apply the Axway_Installer_4.8.0_UP2-from-4.5.x-4.6.1-4.7.0_*****_multiOS_BN2.jar.
Example: Axway_Installer_4.8.0_UP2-from-4.5.x-4.6.1-4.7.0_win-x86_multiOS_
BN2.jar
Step 6: Upgrade to Transfer CFT 3.1.3
Windows: update32.exe o r update64.exe
Unix/Linux: update.sh
2. Apply the Transfer_CFT_3.1.3_UP1-from-2.6.2-2.6.3-2.6.4-2.7.0-2.7.1-3.0.1-3.1.2_*****_
BN8294000.jar
Example: Transfer_CFT_3.1.3_UP1-from-2.6.2-2.6.3-2.6.4-2.7.0-2.7.1-3.0.1-3.1.2_
win-x86-64_BN8294000.jar
Step 7: Upgrade To the latest Transfer CFT 3.1.3 Service Pack
Use the Axway installer in update mode.
1. Start the Axway Installer:

2. Apply the Transfer_CFT_3.1.3_SP*****.zip
Where ***** represents the SP level and the p latform
For example, Transfer_CFT_3.1.3_SP3_aix-power-64_BN8712000.zip
Note In this step you are working with a zip file (not a jar file as in earlier Installer versions). Do
NOT unzip/uncompress the zip file.
3. If necessary, add the Transfer CFT 3.x license key in the conf/cft.key file.
Use the Axway Installer in update mode.
Interactive mode: update32.exe o r update64.exe
Silent mode: update32.exe -i <zip_file> or update64.exe -i <zip_file>
2. Apply the Transfer_CFT_3.y.z_UP****-from-3.1.3_*****_BN*****.zip.
For example, Transfer_CFT_3.3.2_UP1-from-3.1.3_aix-power-32_BN9815000.zip


This procedure requires that your current installation be at least at the levels listed below.
l Transfer CFT version 2.7.1_SP10
l Axway Installer version 4.4.0_SP8 or 4.4.1_SP3
l Embedded JRE version: 160
Note Remember to update the product key between versions after upgrading.
Step 1: Upgrade to JRE 160
Use the Axway JREUpdateTool to perform the JRE update.
For example, JREUpdateTool_4.4.0_Utility_win-x86-64_BN1205240348.zip
2. Use the following command to upgrade to Java 1.6:
Step 2: Upgrade to the Axway Installer 4.5.0_SP4 or the latest SP
Run the Axway installer in update mode.
1. Start the Axway Synchrony Installer:
2. Apply the Synchrony_Installer_4.5.0_UP1-from-4.4.0-4.4.1_allOS_BN1204251050.jar.
Note The program commands change in this step!
4. Apply the Axway_Installer_4.5.0_SP4_allOS_BN22715.jar.
Step 3: Upgrade to JRE 160 update 37
Use the Axway JREUpdateTool to update the JRE level.
For example, JREUpdateTool_4.5.0_Utility_win-x86-64_BN1211090726.zip
Windows: <JRETOOLS_DIRECTORY_WITHOUT_BLANKS>\updatejre.bat
C:\Axway\Synchrony\

2. Apply the Axway_Installer_4.8.0_UP**-from-4.5.x-4.6.1-4.7.0_*****_multiOS_BN2.jar
Where ** is the UP number, and ***** represents the platform.
For example, Axway_Installer_4.8.0_UP2-from-4.5.x-4.6.1-4.7.0_win-x86_multiOS_
BN2.jar
2. Apply the Transfer_CFT_3.1.3_UP1-from-2.6.2-2.6.3-2.6.4-2.7.0-2.7.1-3.0.1-3.1.2_*****_
BN8294000.jar
For example, Transfer_CFT_3.1.3_UP1-from-2.6.2-2.6.3-2.6.4-2.7.0-2.7.1-3.0.1-
3.1.2_win-x86-64_BN8294000.jar
Step 6: Upgrade to the latest Transfer CFT 3.1.3 Service Pack
For example, Transfer_CFT_3.1.3_SP3_aix-power-64_BN8712000.zip
Note In this step you are now working with a zip file (it was .a jar in previous Installer versions).
Do NOT unzip the zip file.
1. Start the Axway Installer using one of the two installation methods:
2. Apply the Transfer_CFT_3.x.y_UP****-from-3.1.3_*****_BN*****.zip.
For example, Transfer_CFT_3.3.2_UP1-from-3.1.3_aix-power-32_BN9815000.zip

NOT unzip the zip file.


This procedure requires that your current installation is at least at the levels listed below.
l Transfer CFT 3.0.1_SP9
l Installer 4.5.0_SP4
l Embedded JRE version: JRE 160
Note Remember to update the product key between versions (after completing the upgrade).
Use the Axway Installer in update mode:
2. Apply Axway_Installer_4.8.0_UP2-from-4.5.x-4.6.1-4.7.0_*****_multiOS_BN2.jar
For example, Axway_Installer_4.8.0_UP2-from-4.5.x-4.6.1-4.7.0_win-x86_multiOS_
BN2.jar
2. Apply the Transfer_CFT_3.1.3_UP**-from-2.6.2-2.6.3-2.6.4-2.7.0-2.7.1-3.0.1-3.1.2_*****_
BN8294000.jar
Where ** is the UP version and ***** represents the platform.
Example: Transfer_CFT_3.1.3_UP1-from-2.6.2-2.6.3-2.6.4-2.7.0-2.7.1-3.0.1-3.1.2_
win-x86-64_BN8294000.jar
Example: Transfer_CFT_3.1.3_SP3_aix-power-64_BN8712000.zip

Note In this step you are working with a zip file (it was a jar in previous Installer versions). Do
For example, Transfer_CFT_3.2.4_UP1-from-3.1.3-3.2.2_win-x86-64_
BN10690000.zip


The current installation must be at least at the levels listed below.
l Transfer CFT version is 3.1.3
Note Remember to update the product key between versions.
1. Launch the Axway Installer:
Example: Transfer_CFT_3.1.3_SP3_aix-power-64_BN8712000.zip
Note In this step you are working with a zip file (and not a jar as in earlier Installer versions). Do
BN10690000.zip


Upgrade to Transfer CFT 3.3.2
BN10690000.zip

Post upgrade
After completing the upgrade procedure, your Transfer CFT 3.3.2, exec scripts are operational.
However, you must rebuild your programs that use C and COBOL APIs and exits.
After performing an upgrade, all passwords are cyphered using a hard-coded key. We recommend
that you generate an encryption key as described in Generate an encryption.
Checking the new version

To check the Transfer CFT version, as well as the license key and system information, enter the
command:
CFTUTIL ABOUT

Upgrade a Transfer CFT multi-node installation

This section describes how to upgrade from a Transfer CFT 3.0.1, 3.1.2, or 3.1.3 multi-node,
multihost installation to Transfer CFT 3.2.x.
Before you start

Before beginning the upgrade procedure:
appropriate procedure. See Upgrade Transfer CFT on page 73.
l Download the Transfer CFT Upgrade Pack, available at support.axway.com.
l Stop the Transfer CFT server and the Transfer CFT UI server, by entering:
o cft stop
o copstop -f
Note Transfer CFT clusters must be fully stopped while performing an upgrade.

Upgrade from Transfer CFT 3.0.1 multi-node

For details on shared disks, node commands, and other multi-node considerations, refer to the
Transfer CFT 3.3.2 User Guide > Manage multi-node architecture.
Upgrade all hosts

1. Stop Copilot. This command stops Copilot as well all cftnodes running on that machine.
copstop -f
2. Connect to each machine and perform the following tasks:
l Launch the Transfer CFT profile from the Transfer CFT runtime directory on the shared disk. For
example:
cd /<shared_disk>/<CFTdir>/Transfer_CFT/runtime
profile.bat
l Begin the upgrade procedure as described in Upgrade from Transfer CFT 3.0.1.
Restart the upgraded Transfer CFT multi-node

multihost environment
1. Launch the Transfer CFT profile from the Transfer CFT runtime directory on the shared disk.
profile.bat
2. Check the new version using the following command:
CFTUTIL ABOUT
3. Start Copilot (start each of the Copilots in the multi-node environment).
copstart
4. After restarting the Copilots, restart the Transfer CFT server.
cft restart
5. Check the upgraded Transfer CFT multi-node multihost system.
CFTUTIL listnode

l All of the Copilot should be started
l All of the Transfer CFT nodes must be started
Once Transfer CFT has been upgraded on a host you can start that instance, there is no need to wait
until Transfer CFT is upgraded on every host.

Upgrade from Transfer CFT 3.1.2 multi-node

For details on shared disks, node commands, and other multi-node considerations, refer to the
Transfer CFT 3.3.2 User Guide > Manage multi-node architecture.
Upgrade all hosts

1. Stop Copilot. This command stops Copilot as well all cftnodes running on that machine.
copstop -f
2. Connect to each machine and perform the following tasks:
l Launch the Transfer CFT profile from the Transfer CFT runtime directory on the shared disk. For
example:
profile.bat
l Begin the upgrade procedure as described in Upgrade from Transfer CFT 3.1.2.
Restart the upgraded Transfer CFT multihost multi-

node environment
1. Launch the Transfer CFT profile from the Transfer CFT runtime directory on the shared disk.
profile.bat
2. Check the new version using the following command:
CFTUTIL ABOUT
3. Start Copilot (start each of the Copilots in the multi-node environment).
copstart
4. After restarting the Copilots, restart the Transfer CFT server:
cft restart
5. Check the upgraded Transfer CFT multi-node multihost system.
CFTUTIL listnode

l All of the Copilot should be started
l All of the Transfer CFT nodes must be started
Once Transfer CFT has been upgraded on a host you can start that instance, there is no need to wait
until Transfer CFT is upgraded on every host.

Post upgrade
After completing the upgrade procedure, your Transfer CFT 3.3.2, exec scripts are operational.
However, you must rebuild your programs that use APIs and exits.
After performing an upgrade, all passwords are cyphered using a hard-coded key. We recommend
that you generate an encryption key as described in Generate an encryption.
Display product information

The display command lists information about all installed products.
l Run the command from the root installation directory.
l When you run this command without parameters, the command lists all installed products and
versions, and all applied service packs.
Use the name parameter to display the installation history of a single product.
Windows
display.bat
UNIX
./display.sh
How to free disk space from service packs

This topic describes how to reclaim disk space that is taken up by Service Packs and updates applied
to Transfer CFT over time.
Use the purge command

Use the purge command followed by the appropriate options to removed accumulated backups of
installed Transfer CFT updates.
1. Navigate to the Transfer CFT installation directory.
2. Run the purge command as described in the following sections.
Syntax
purge [-h | --help] | [-k | --keep] [number] [-p | --pretend]
l Windows: purge64.exe or purge32.exe ( from a command line window)
Where:

l [-h | --help]: Displays the command help.
l [-k | --keep] [number]: Specifies the number of updates that should be kept.
l [-p | --pretend]: Previews the action to be done.
Examples
Keep only the last backup, meaning you can remove the current patch or SP.
<Transfer_CFT_install_dir>/purge.sh -k 1
Remove all backups, meaning that you cannot remove the current patch or SP.
<Transfer_CFT_install_dir>/purge.sh -k 0
<Options> include:
l [-d | --debug]: Generates debug information in the log file.
Example
<Transfer_CFT_install_dir>/purge.sh -k 1 -d
Perform a manual migration
Migration prerequisites
After performing a Transfer CFT 3.3.2 installation, you should update to the most recent service
pack.
You require a new license key if you are migrating from a version 2.x Transfer CFT to a version 3.x.
Note You require as many keys as instances of Transfer CFT running at same time, including
when running in multi-node. For example, two Transfer CFT instances cannot run at the
same time, on the same server, using the same license key.
Check the TLS version

As of Transfer CFT 3.2.0, the use of cipher suites 59, 60, and 61 is restricted to TLS 1.2
exclusively. This means that if some of your partners use a version of Transfer CFT lower than 3.2.0
that does not support TLS 1.2, and you are using ciphers 59, 60 and 61, which requires TLS 1.2 in
version 3.2.0 and higher, you must add another cipher in the cipher list and remove ciphers 59, 60,
61 from the partner's cipher list.
Note You do not have to remove ciphers 59, 60, 61 in the partner cipher list if you apply the
Transfer CFT patch 3.0.1 SP11.

CA certificate chains
In Transfer CFT 3.1.3 and lower, you can perform a SSL transfer even if the certificate chain is not
complete (not signed by a ROOT CA). However, for Transfer CFT 3.2.0 and higher, the certificate
chain must be complete for a transfer to succeed.
For more information, see Unknown CA leads to a failed certificate verification.
Windows x86 operating system prerequisite

When using a Windows x86 (32-bit) or (64-bit) system, you must install the Visual C++
Redistributable Package for Visual Studio 2013 ( not a later version) to provide necessary
library files (DLL) for the compiler:
Note If the redistribution package is already installed on your Windows system, there is no need
to reinstall.
Install Transfer CFT 3.3.2

Perform a Transfer CFT installation, as described in the OS-specific installation section.
Note Do not use the Install auto-import option available in the Installer.
Load the environment

Before beginning a standard migration procedure, you must load the old Transfer CFT environment.
Windows procedure
Transfer CFT 2.3.2 and 2.4

There is no profile file for Transfer CFT 2.3.2 or 2.4 in Windows.
To execute a command you must be in the correct directory. Therefore, before starting the
migration, change the directory to the version-appropriate Transfer CFT installation directory.
Transfer CFT 2.5 and higher

From the console, change the directory to the Transfer CFT runtime directory and execute the profile
file using the command: profile.bat
After loading the profile, you can execute commands from anywhere.

Install and auto import

The install and auto import option allows you to preform a new Transfer CFT installation and import
configuration files and data from a existing Transfer CFT instance. During the procedure, you can
select options for your new instance, and additionally can select which of the available types of data
and configuration elements that you want to import.
Note Previous versions that are available for auto importing the configuration data include
v2.3.2, 2.4, v2.5, v2.6, v2.7, v3.0.1, v3.1.x, and v3.2.x.
To check the Transfer CFT version, as well as the license key and system information, enter the
command:
CFTUTIL ABOUT
You require a new license key if you are migrating from a version 2.x Transfer CFT to a version 3.x.
Procedure
Run the installer to perform a new Transfer CFT installation. During this process you are prompted
with the option of importing existing data and configuration.
Start your installation

Begin a typical installation using the Transfer CFT 3.3.2 installation instructions that correspond to
your operating system.
Importing configuration and data

Pending the existing version of Transfer CFT, the installer will propose available import options.
Auto import screens

At this point you can select to migrate. The Installer page asks if you want to import data from your
existing Transfer CFT instance. In the following screen you can select which types of data you'd like
to import.
1. Select Yes to perform an automatic migration. Click Next.

2. Enter or navigate to the path for the existing profile file (profile.bat or profile.sh) for version 2.5
and higher. The profile file should be located in the runtime folder of the existing Transfer CFT
installation.
3. Click to select configuration elements and objects that you want to import from the existing
Transfer CFT instance. You must manually migrate execs, exits, and APIs.

Identity
1. You are prompted to confirm the local instance details. Modify if necessary, and click Next to
continue.
2. Check the license key.
Post auto import

If you used the install and auto import procedure with your existing Transfer CFT to Transfer CFT
3.3.2, at the end of the installation a new directory called migration is created in the runtime
directory. This directory stores all of the information used during the auto import process. You can
modify the extracted files and/or directory, and manually re-import this data at any time.
The contents of this Auto import directory are described in the following table.
File Directory Description of extracted data
cftcat.xml Catalog file.
cftcom.xml Communication media.
cft-conf.cfg Transfer CFT general configuration, which is applied to
the new installation (contained in CFTPARM/CFTPART
internal datafiles).
cft-conf- Contains file path declarations from the cft-conf.cfg file
warning.txt that were used in the former Transfer CFT environment
and that cannot be imported into the new installation.
cft-pki.cfg The PKI configuration that is applied to the new
installation (as of version 2.4).
PKI directory Contains extracted SSL certificates (pending version).
cft-uconf. Contains:
(sh/bat)
l UCONF parameters (as of V2.5.1)
or
l Sentinel parameters (TRKAPI.cfg -
V2.3.2 and V2.4.x)
and/or
l Copilot parameters (copconf.ini -
V2.4.x)
This file is used to set the new installation UCONF
parameters.

cft-uconf- Contains UCONF parameters set by the user in the former
warning.txt Transfer CFT environment and that cannot be imported
into the new installation.
migration. Contains instructions on how to re-import the collected
(sh/bat) data into a new installation, and includes the PKI,
general configuration, UCONF parameters, catalog and
communication media files.
Auto import in multi-node architecture

This section describes how to proceed to use auto import for Transfer CFT 3.0.1, 3.1.3, or 3.2.x
multi-node in multi-hosts.
Procedure
On the first host:
The automatic import is performed during the Transfer CFT 3.3.2 installation. During the
installation, dialog boxes let you select configuration data from the existing Transfer CFT to import.
While installing first node on cluster architecture, you should opt to import data from the previous
Transfer CFT version. Execute the procedure as described here. During installation of additional
nodes, the option of importing data from previous version of Transfer CFT should not be selected.
If you choose to migrate your existing Transfer CFT to 3.3.2 using the automatic import method, at
the end of the installation a new directory called auto_import is created in the runtime directory.
This directory stores all of the information used during the installation and auto import. You can
modify the extracted files and/or directory, and manually re-import this data at any time.
If you are installing and performing an auto import from a Transfer CFT with multi-node architecture
enabled, the contents of the Auto_import directory are as shown in the table below.
On additional hosts:
Repeat the installation steps, indicating the appropriate shared directories. See the information
provided in .
Table 1. Auto_import directory
cftcatXX.xml Catalog files. XX represents the node number, from 00
to Total_Number_of_Nodes -1.
cftcom.xml Communication media for node manager.

cftcomXX.xml Communication media for nodes. XX represents the
node number, from 00 to Total_Number_of_Nodes -1.
cft-conf.cfg Transfer CFT general configuration, which is applied to
the new installation (contained in CFTPARM/CFTPART
internal datafiles).
cft-conf- Contains file path declarations from the cft-conf.cfg file
warning.txt that were used in the former Transfer CFT environment
and that cannot be imported into the new installation.
cft-pki.cfg The PKI configuration that is applied to the new
installation, as of version 2.4.
PKI directory Contains extracted SSL certificates (pending version).
cft-uconf. Contains:
(sh/bat)
l UCONF parameters (as of V2.5.1)
- or -
l Sentinel parameters (TRKAPI.cfg -
V2.3.2 and V2.4.x)
- and/or -
l Copilot parameters (copconf.ini -
V2.4.x)
This file is used to set the new installation UCONF
parameters.
cft-uconf- Contains UCONF parameters set by the user in the
warning.txt former Transfer CFT environment and that cannot be
imported into the new installation.
migration. Contains instructions on how to re-import the collected
(sh/bat) data into a new installation, and includes the PKI,
general configuration, UCONF parameters, catalog and
communication media files.
Migrating from Transfer CFT 2.3.2 to 3.3.2

This topic describes how to migrate Transfer CFT 2.3.2 to 3.3.2.

Migrating the configuration
Migrating the main configuration

Migrate PARM, PART, IDF and other static configuration objects.
1. Load the Transfer CFT 2.3.2 environment. See the Migration prerequisites on page 92
for details.
2. Export your static configuration objects using the command CFTUTIL CFTEXT. Enter:
CFTUTIL CFTEXT type=all, fout=cft-extract.conf
3. Open the extract configuration files, cft-extract.conf, and update the file paths with
those of the Transfer CFT 3.3.2 installation.
4. Load the Transfer CFT 3.3.2 environment.
5. Stop Transfer CFT if you have not already done so.
6. Import your static configuration objects using the cftinit command. Enter:
cftinit cft-extract.conf
Migrating trkapi.cfg file parameters

1. In the trkapi.cfg file, select the parameters you want to import into 3.3.2.
2. Create a script file, for example:
o Windows: trkapi-import.bat
3. For each parameter you select, add a UCONF command line to your new script file
using the format: UCONFSET id=<parameter_id>, value=<value>
4. Use the parameter mapping between trkapi and UCONF, as listed in the following
table, to specify the correct parameter id.
Table 2. Parameter mapping between the trkapi.cfg file and UCONF
Parameter in trkapi.cfg Parameter names in UCONF
TRACE sentinel.trktrace
TRKGMTDIFF sentinel.trkgmtdiff
TRKIPADDR_BKUP sentinel.trkipaddr_bkup
TRKIPPORT sentinel.trkipport

TRKIPPORT_BKUP sentinel.trkipport_bkup
TRKLOCALADDR sentinel.trklocaladdr
TRKPRODUCTNAME sentinel.trkproductname
XFB.BufferSize sentinel.xfb.buffer_size
XFBLOG (Windows) sentinel.xfb.log
XFB.Sentinel sentinel.xfb.enable
XFB.Trace sentinel.xfb.trace
XFB.Transfer sentinel.xfb.transfer
Load the Transfer CFT 3.3.2 environment.
5. Import the selected UCONF parameters using the command CFTUTIL. Replace <script_
filename> with the new script file path: CFTUTIL <prefix_character><script_
filename>
Example
l Windows: CFTUTIL #trkapi-import.bat
Migrating PKI certificates

Exporting PKI certificates from Transfer CFT 2.3.2 is not supported. For this reason, you must create
a new PKI database in the Transfer CFT 3.3.2 runtime using the PKIUTIL PKIFILE command. Next
import each certificate using the PKIUTIL PKICER command.
For more information, refer to the Transfer CFT 3.3.2 User's Guide, sections Using the PKIFILE
command and Using the PKICER command.
Migrating the runtime environment
Migrating the catalog

2. Export the catalog using the command CFTMI230:
CFTMI230 MIGR type=CAT, direct=FROMCAT, ifname=<catalog_2.3.2_

filename>, ofname=catalog_output.xml

3. Import the catalog using the command CFTMI. Replace the <catalog_filename_new_
installation> with the corresponding environmental variable:
o Windows: $CFTCATA
CFTMI MIGR type=CAT, direct=TOCAT, ifname=catalog_output.xml,

ofname=<catalog_filename_new_installation>
Migrating the communication media files

2. Export the communication media file using command CFTMI230:
CFTMI230 MIGR type=COM, direct=FROMCOM, ifname=<com_2.3.2_filename>, ofname=com_
output.xml
3. Import the communication media file using command CFTMI. Replace the <com_
filename_new_installation> with the system-specific environment variable:
o Windows: $CFTCOM
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml, ofname=<com_

filename_new_installation>
Migrating from Transfer CFT 2.4 to 3.3.2

This topic describes how to migrate from Transfer CFT 2.4 to version 3.3.2. Before starting this
migration procedure you must perform the steps described in Before you start.

1. Load the Transfer CFT 2.4 environment. See the Migration prerequisites on page 92 for
details.
2. Export your static configuration objects using the command CFTUTIL CFTEXT.
Enter: CFTUTIL CFTEXT type=all, fout=cft-extract.conf
those of the Transfer CFT 3.3.2 installation.

Migrating trkapi.cfg file parameters

Migrate the parameters from the Transfer CFT 2.4 trkapi.cfg file.
1. In the trkapi.cfg file, select the parameters you want to import in 3.3.2.
o Windows: trkapi-import.bat
3. For each parameter you select, add a UCONF command line to your new script file
using the format:
UCONFSET id=<parameter_id>, value=<value>
Use the parameter mapping between trkapi and UCONF, as listed in the following table, to specify
the correct parameter id.
Table 3. Parameter mapping between the trkapi.cfg file and UCONF
TRACE sentinel.trktrace
TRKGMTDIFF sentinel.trkgmtdiff
TRKIPADDR_BKUP sentinel.trkipaddr_bkup
TRKIPPORT sentinel.trkipport
TRKIPPORT_BKUP sentinel.trkipport_bkup
TRKLOCALADDR sentinel.trklocaladdr
TRKPRODUCTNAME sentinel.trkproductname
XFB.BufferSize sentinel.xfb.buffer_size
XFBLOG (Windows) sentinel.xfb.log
XFB.Sentinel sentinel.xfb.enable
XFB.Trace sentinel.xfb.trace
XFB.Transfer sentinel.xfb.transfer

5. Import the selected UCONF parameters using the command CFTUTIL. Replace <script_
filename> with the new script file path.
CFTUTIL <prefix_character><script_filename>
Example
l Windows: CFTUTIL #trkapi-import.bat
Migrating copconf.ini parameters

Migrate parameters from the Transfer CFT 2.4 copconf.ini file.
1. From the copconf.ini file, select the parameters you want to import into version 3.3.2.
o Windows: copconf-import.bat
3. For each selected parameter add a UCONF command line in your new script file using
the format:
Use the parameters mapping between copconf and UCONF as listed in the following table to specify
the correct parameter id.
Table 4. Parameter mapping between copconf file and UCONF
Parameter in copconf.ini Parameter name in UCONF
BatchList copilot.batches
CFTCOM copilot.cft.com
CFTMEDIACOM copilot.cft.mediacom
ChildProcessTimeout copilot.misc.childprocesstimeout
HttpRootDir copilot.http.httprootdir
MinNbProcessReady copilot.misc.minnbprocessready
NbProcessToStart copilot.misc.nbprocesstostart
NBWAITCFTCATA copilot.cft.nbwaitcftcata
ServerHost copilot.general.serverhost
ServerPort copilot.general.serverport

Parameter in copconf.ini Parameter name in UCONF
SslCertFile copilot.ssl.sslcertfile
SslCertPassword copilot.ssl.sslcertpassword
SslKeyFile copilot.ssl.sslkeyfile
SslKeyPassword copilot.ssl.sslkeypassword
TcpTimeout copilot.misc.tcptimeout
TIMERWAITCFTCATA copilot.cft.timerwaitcftcata
TrcMaxLen copilot.trace.trcmaxlen
TrcType copilot.trace.trctype
wlogComment copilot.batches.wlog.comment
wlogParams copilot.batches.wlog.params
WsiComplience copilot.webservices.wsicomplience
5. Import the selected UCONF parameters using the command CFTUTIL. Replace the
<script_filename> with the new script file path.
Example
l Windows: CFTUTIL #copconf-import.bat

You must be at Transfer CFT 2.4.1 SP5 or higher before performing this procedure.
1. Load the Transfer CFT 2.4 environment.
2. Export your PKI certificates using the command PKIUTIL PKIEXT:
PKIUTIL PKIEXT fout=pki-extract.conf
3. Load the new Transfer CFT 3.3.2 environment.
4. Create a new PKI internal datafile using the command PKIUTIL PKIFILE. Replace <pki_
database_filename> with the appropriate variable:
o Windows: The absolute path value for the CFTPKU environment variable

PKIUTIL PKIFILE fname=<pki_database_filename>, mode='CREATE’
5. Import your PKI certificates into Transfer CFT 3.3.2 using the command PKIUTIL.
Replace the <script_filename> with the new script file path.
PKIUTIL <prefix_character><script_filename>
Example
l Windows: PKIUTIL #pki-extract.conf

1. Load the Transfer CFT 2.4 environment.
CFTMI240 MIGR type=CAT, direct=FROMCAT, ifname=<catalog_2.4_filename>,

ofname=catalog_output.xml
installation> with the corresponding environment variable:
o Windows: $CFTCATA


1. Load the Transfer CFT V2.4 environment.
CFTMI240 MIGR type=COM, direct=FROMCOM, ifname=<com_2.4_filename>,

ofname=com_output.xml
3. Load Transfer CFT 3.3.2 environment.
4. Import the communication media file using command CFTMI. Replace <com_
filename_new_installation> with the corresponding environment variable:
o Windows: $CFTCOM


Migrate from Transfer CFT 2.5 or 2.6 to 3.3.2

This topic describes how to migrate Transfer CFT 2.5 or 2.6 to version 3.3.2.
Migrate the configuration

1. Load the former Transfer CFT (2.5 or 2.6) environment. See the Migration
prerequisites on page 92 for details.
those of the new Transfer CFT 3.3.2 installation.
6. Import your static configuration objects using the cftinit command.
Enter:
Migrating UCONF parameters

1. Load the former Transfer CFT (2.5 or 2.6) environment.
2. Display your UCONF parameters using the CFTUTIL LISTUCONF command. Enter:
CFTUTIL LISTUCONF scope=user
3. Select the UCONF parameters that you want to import into the new Transfer CFT 3.3.2.
4. Create a script file such as:
l Windows: uconf-import.bat
5. For each parameter you select, add a line to the new script file in the format:

7. Import the selected UCONF parameters using the script file and the CFTUTIL
command. Replace the <script_filename> with the new script file path:
Example
l Windows: CFTUTIL #uconf-import.bat

For Transfer CFT 2.5, you must be at Transfer CFT 2.5.1 SP2 or higher before performing this
procedure. For Transfer CFT 2.6.4, you must be at Transfer CFT 2.6.4 SP2 or higher before
performing this procedure.
1. Load the former Transfer CFT environment (2.5 or 2.6).
2. Export your PKI certificates using the command PKIUTIL PKIEXT: PKIUTIL PKIEXT
fout=pki-extract.conf
database_filename> with the appropriate value: PKIUTIL PKIFILE fname=<pki_
database_filename>, mode='CREATE’
l Windows: The absolute path value for the CFTPKU environment variable
5. Import your PKI certificates into the new Transfer CFT 3.3.2 using the command
PKIUTIL. Replace the <script_filename> with the new script file path: PKIUTIL
<prefix_character><script_filename>
Example
l Windows: PKIUTIL #pki-extract.conf

2. Export the catalog using the command CFTMI240.
CFTMI240 MIGR type=CAT, direct=FROMCAT, ifname=<catalog_2.5_filename>,

ofname=catalog_output.xml

l Windows: $CFTCATA
Table 5. Example


CFTMI240 MIGR type=COM, direct=FROMCOM, ifname=<com_2.5_filename>,

ofname=com_output.xml
o Windows: $CFTCOM
Table 6. Example

Migrating Transfer CFT 2.6.4 SP2 or 2.7 to 3.3.2

This topic describes how to migrate Transfer CFT 2.6.4 SP2, or higher, or 2.7 to version 3.3.2.
Migrating the main configuration and UCONF

parameters
You can migrate the PARM, PART, IDF, other static configuration objects and UCONF parameters as
follows:
1. Load the former Transfer CFT environment. See the Migration prerequisites on page 92
for details.
2. Export your static configuration objects using the command CFTUTIL CFTEXT.
Enter:


1. Load the former Transfer CFT (2.6.4 or 2.7) environment.
2. Export your PKI certificates using the command PKIUTIL PKIEXT. Enter:
database_filename> with the OS appropriate value:
Windows: The absolute path value for the CFTPKU environment variable:
5. Import your PKI certificates into the new Transfer CFT 3.3.2 using the command
PKIUTIL. Replace the <script_filename> with the new script file path:
PKIUTIL <prefix_character><script_filename>
Examples
Windows: PKIUTIL #pki-extract.conf

1. Load the former Transfer CFT (2.6.4 or 2.7) environment.
CFTMI240 MIGR type=CAT, direct=FROMCAT,

ifname=<catalog_2.7_filename>, ofname=catalog_
output.xml

Windows: $CFTCATA
Example


1. Load the former Transfer CFT (2.6.4 or 2.7.0) environment.
CFTMI240 MIGR type=COM, direct=FROMCOM, ifname=<com_

2.7.0_filename>, ofname=com_output.xml
3. Load the new Transfer CFT3.3.2 environment.
Windows: $CFTCOM
Example

Migrating Transfer CFT 3.0.1 or 3.1.x to 3.3.2

This topic describes how to migrate Transfer CFT 3.0.1 or 3.1.2 to version 3.3.2. It is divided in 2
sections, the first section describes migration for a single node architecture, and the second section
multi-node architecture. Lastly there are instructions explaining what would be needed to migrate
from single node architecture to multi node architecture.
Note When migrating from 3.0.1 to 3.3.x, you must install SP10 P6 on all Transfer CFTs v3.0.1
that inter-operate with any Transfer CFTs v3.3.x prior to migrating.

Single node architecture
Migrating the main configuration and UCONF parameters

Migrate PARM, PART, IDF, other static configuration objects and UCONF parameters as follows:
1. Load former Transfer CFT 3.0.1 or 3.1.x environment. See the Migration prerequisites
on page 92 for details.

1. Load former Transfer CFT 3.0.1 or 3.1.2 environment.
database_filename> with the appropriate value: $CFTPKU for UNIX, the absolute path
value for the CFTPKU for Windows. Enter:
PKIUTIL PKIFILE fname=<pki_database_filename>,

mode='CREATE’
Replace the <prefix_character> based on your system, @ for UNIX and # for
Windows.
Enter:

PKIUTIL <prefix_character>pki-extract.conf

2. Export the catalog using the command CFTMI. Replace the <catalog_filename > with
the corresponding environment variable, _CFTCATA for UNIX or $CFTCATA for
Windows. Enter:
CFTMI MIGR type=CAT, direct=FROMCAT, ifname=<catalog_

filename_former_cft>, ofname=catalog_output.xml
4. Import the catalog using the command CFTMI. Replace the <catalog_filename > with
the corresponding environment variable, _CFTCATA for UNIX or $CFTCATA for
Windows. Enter:
CFTMI MIGR type=CAT, direct=TOCAT, ifname=catalog_

output.xml, ofname=<catalog_filename_new_cft >

2. Export the communication media file using command CFTMI. Replace the <com_
filename > with the corresponding environment variable, _CFTCOM for UNIX, or
$CFTCOM for Windows. Enter:
CFTMI MIGR type=COM, direct=FROMCOM, ifname=<com_

filename_former_cft>, ofname=com_output.xml
filename > with the corresponding environment variable, _CFTCOM for UNIX or
$CFTCOM for Windows. Enter:
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_

ouput.xml, ofname=<com_filename_new_cft >

Executables and binaries

Remember that you can copy your post-processing scripts directly from the runtime/exec to the new
version (3.3.2). When you copy files from the exec folder, be certain to modify any paths that point
to the former version (for example, 3.0.1, 3.1.3 or 3.2.x). However, you must rebuild APIs and
EXITS (binaries).
Multi-node architecture


2. Export your PKI certificates using the command PKIUTIL PKIEXT. Enter: PKIUTIL
PKIEXT fout=pki-extract.conf
database_filename> with the appropriate value, $CFTPKU for UNIX or the absolute
path value for the CFTPKU for Windows. Enter:
PKIUTIL PKIFILE fname=<pki_database_

filename>, mode='CREATE’
Replace the <prefix_character> based on your system, @ for UNIX and # for

Windows. Enter:

2. Export all catalogs (one per node, named as cftcataXX, where XX is the node number
with range from 00 to <number of nodes - 1>) using the command CFTMI. For each
catalog. Enter:
CFTMI MIGR type=CAT, direct=FROMCAT,

ifname=<catalog_filename_former_cft_for_node_
<node>>, ofname=catalog_output_<node>.xml
4. Import all catalogs using the command CFTMI for each of them. Use the same node
number on both <node> on command. Enter:
CFTMI MIGR type=CAT, direct=TOCAT, ifname=catalog_

output_<node>.xml, ofname=<catalog_filename_new_
cft><node>

2. Export all communication media files (cftcom and cftcomXX, where XX is the node
number with range from 00 to <number of nodes - 1>) using the command CFTMI.
For each communication media file.
l Enter: CFTMI MIGR type=COM, direct=FROMCOM,
ifname=<com_filename_for_node_manager_on_
former_cft>, ofname=com_output.xml
l For each node, enter: CFTMI MIGR type=COM,
direct=FROMCOM, ifname=<com_filename_for_
node_<node>_on_former_cft>, ofname=com_
output_<node>.xml

4. Import all communication media files using command CFTMI for each of them. Use the
same node number on both <node> on command.
l Enter: CFTMI MIGR type=COM, direct=TOCOM,
ifname=com_ouput.xml, ofname=<com_filename_
for_node_manager_on_new_cft>
l For each node, enter: CFTMI MIGR type=COM,
direct=TOCOM, ifname=com_ouput_<node>.xml,
ofname=<com_filename_for_node_<node>_on_
new_cft>
Single-node to multi-node architecture migration

The only difference between migrating from single node to multi-node architecture and migrating
from single-node to single-node architecture is the catalog migration step. Since there is no catalog
named cftcata in multi-node, import the catalog exported from single-node architecture to the
catalog of any of the nodes in the multi-node architecture.
Migrating Transfer CFT 3.2.x to 3.3.2

This topic describes how to migrate Transfer CFT 3.2.x (either 3.2.2 or 3.2.4) to version 3.3.2. It is
divided in 2 sections, the first section describes migration for a single node architecture, and the
second section multi-node architecture. Lastly there are instructions explaining what would be
needed to migrate from single node architecture to multi node architecture.
Single node architecture

Stop Transfer CFT and the Copilot server before starting the migration.

1. Load former Transfer CFT 3.2.x environment. See the Migration prerequisites on page 92 for
details.
3. Open the extract configuration files, cft-extract.conf, and update the file paths with those of
the new Transfer CFT 3.3.2 installation.


1. Load former Transfer CFT 3.2.x environment.
3. Copy all files that are referenced in the pki-extractconf file (INAME OR IKNAME) to the folder
where you are going to execute the PKI command on the new version. In the following
example, copy ROOT0001 to the new folder in Transfer CFT 3.3.2.
PKICER ID = 'LOCALROOT',
ROOTCID = 'LOCALROOT',
ITYPE = 'ROOT', /*
PKIFNAME = '',*/ /*
COMMENT = '',*/
INAME = 'ROOT0001',
IFORM = 'DER', /*
IKNAME = '',*/ /*
IKFORM = '',*/ /*
FOUT = '',*/
MODE = 'REPLACE'
database_filename> with the appropriate value: $CFTPKU for UNIX, the absolute path value
for the CFTPKU for Windows. Enter:
6. Import your PKI certificates into Transfer CFT 3.3.2 using the command PKIUTIL. Replace the
<prefix_character> based on your system, @ for UNIX and # for Windows.
Enter:


2. Export the catalog using the command CFTMI. Replace the <catalog_filename > with the
corresponding environment variable, _CFTCATA for UNIX or $CFTCATA for Windows. Enter:
CFTMI MIGR type=CAT, direct=FROMCAT, ifname=<catalog_filename_

former_cft>, ofname=catalog_output.xml
4. Import the catalog using the command CFTMI. Replace the <catalog_filename > with the
corresponding environment variable, _CFTCATA for UNIX or $CFTCATA for Windows. Enter:

ofname=<catalog_filename_new_cft >

2. Export the communication media file using command CFTMI. Replace the <com_filename >
with the corresponding environment variable, _CFTCOM for UNIX, or $CFTCOM for Windows.
Enter:
CFTMI MIGR type=COM, direct=FROMCOM, ifname=<com_filename_

former_cft>, ofname=com_output.xml
4. Import the communication media file using command CFTMI. Replace the <com_filename >
with the corresponding environment variable, _CFTCOM for UNIX or $CFTCOM for Windows.
Enter:
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml,

ofname=<com_filename_new_cft >
Executables and binaries

Remember that you can copy your post-processing scripts directly from the runtime/exec to the new
version (3.3.2). When you copy files from the exec folder, be certain to modify any paths that point
to the former version (3.2.x in this case). However, you must rebuild APIs and EXITS (binaries).

Migrate a multi-node to multi-node architecture

Stop Transfer CFT and the Copilot server before starting the migration.

3. Open the extract configuration files, cft-extract.conf, and update the file paths with those of
the new Transfer CFT 3.3.2 installation.

database_filename> with the appropriate value, $CFTPKU for UNIX or the absolute path value
for the CFTPKU for Windows. Enter:
5. Import your PKI certificates into Transfer CFT 3.3.2 using the command PKIUTIL. Replace the
<prefix_character> based on your system, @ for UNIX and # for Windows. Enter:


2. Export all catalogs (one per node, named as cftcataXX, where XX is the node number with
range from 00 to <number of nodes - 1>) using the command CFTMI. For each catalog. Enter:
CFTMI MIGR type=CAT, direct=FROMCAT, ifname=<catalog_filename_

former_cft_node_<node>>, ofname=catalog_output_<node>.xml
4. Import all catalogs using the command CFTMI for each of them. Use the same node number on
both <node> on command. Enter:
CFTMI MIGR type=CAT, direct=TOCAT, ifname=catalog_output_

<node>.xml, ofname=<catalog_filename_new_cft_node_<node>>

2. Export all communication media files (cftcom and cftcomXX, where XX is the node number with
range from 00 to <number of nodes - 1>) using the command CFTMI.
For each communication media file, enter:
CFTMI MIGR type=COM, direct=FROMCOM, ifname=<com_filename_for_

node_manager_on_former_cft>, ofname=com_output.xml
For each node, enter:
CFTMI MIGR type=COM, direct=FROMCOM, ifname=<com_filename_for_

node_<node>_on_former_cft>, ofname=com_output_<node>.xml
4. Import all communication media files using the CFTMI command.
For the manager, enter:
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml,

ofname=<com_filename_for_node_manager_on_new_cft>
For each node, enter:

CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput_<node>.xml,

ofname=<com_filename_for_node_<node>_on_new_cft>
Single-node to multi-node architecture migration

The only difference between migrating from single node to multi-node architecture and migrating
from single-node to single-node architecture is the catalog migration step. Since there is no catalog
named cftcata in multi-node, import the catalog exported from single-node architecture to the
catalog of any of the nodes in the multi-node architecture.

Activate Central Governance connectivity

Central Governance simplifies the management of Transfer CFT and provides identity and access
management, certificate security services, monitoring, alerting, and web dashboard services. Central
Governance replaces possible existing services from earlier Transfer CFT installations that required
implementing and configuring multiple products, such as Transfer CFT Navigator, PassPort, and
Composer.
You can perform this activation procedure only after completing an upgrade or migration to
Transfer CFT 3.1.3 or higher.
Overview
There are two ways to activate Transfer CFT to Central Governance connectivity following an
upgrade procedure:
l Automatically activate connectivity on page 120
l on page 121
Additional information and tasks:
l Connect to a different Central Governance system on page 124
l Use former configuration objects on page 124
l View managed features on page 124
Automatically activate connectivity

UNIX/Windows
The automatic activation is only available in UNIX/Windows. Please refer to Manually activate
connectivity below for z/OS or IBM i instructions.
This section describes how to run the installer in configure mode to enable Central Governance
connectivity.
Note If running in Windows, the same user who performed the initial installation (or same type
of user) must start the installer.
Prerequisite
You must set the UCONF parameter cg.configuration_policy if you want to override the
default policy applied by Central Governance when you register a Transfer CFT in Central
Governance.

Procedure
1. Stop Transfer CFT and Copilot.
2. Start the installer in configure mode.
GUI
Windows: In Windows Start menu, select Axway Software > Axway [installation

name] > Configure
Console
Windows
3. In the installer screen, select Configure your existing installation.
4. Enter the license key if required.
5. Accept or modify the UI server and service mode screen values.
6. In the Governance Mode screen, select Central Governance.
7. In the CG connectivity screen, enter the Central Governance values. For Transfer CFT
z/OS installations, see Use compliant characters for the z/OS shared secret on page 123.
8. Click Next and complete the configure procedure.
9. Once completed, start Copilot, which automatically completes the registration process.
You can check in Central Governance to see that the Transfer CFT displays in the Product List.
Manually activate connectivity

All OS
This section describes how to manually modify the Transfer CFT configuration to enable Central
Governance connectivity in command line.
Prerequisites
1. Stop Transfer CFT and Copilot if running.
2. Enabling Central Governance c onnectivity after an upgrade implies replacing any standalone
connectors. Therefor, prior to connecting to Central Governance deactivate all previously
activated connectors, for example PassPort AM, PassPort PS, and Sentinel.
CFTUTIL uconfunset id=am.type

CFTUTIL uconfunset id=sentinel.xfb.enable
CFTUTIL uconfset id=pki.type, value=cft

Note When running in a z/OS environment you must additionally set the am.passport.superuser
with the user that will start the Copilot server.
3. Ensure that all UCONF values used to identify a Transfer CFT instance are defined. These
parameters include:
l cft.full_hostname
l cft.instance_id
l cft.instance_group
Use the format:
CFTUTIL uconfset id=cft.instance_id, value=<cft_id>
You must set the UCONF parameter cg.configuration_policy if you want to override the
default policy applied by Central Governance when you register a Transfer CFT in Central
Governance.
Procedure
The manual procedure consists of the following steps, which are detailed below:
1. Include certificates in the PKI database.
2. Set the UCONF parameter values for Central Governance.
3. Enable Central Governance.
4. Start Copilot.
Include certificates
You must include the certificate authority that is used to validate communication with Central
Governance in the PKI database. You can personalize this certificate on the Central Governance side,
so be sure to use the correct iname in the pkicer command.
You can use any ID for this certificate. Transfer CFT uses the certificate ID defined in UCONF to
communicate with Central Governance.
Note Modify the filename syntax to accommodate your specific platform.
PKIUTIL pkicer id = 'CG_CA',

iform = 'PEM',
iname = '$CFTPKIDIR/passportCA.pem',
itype = 'ROOT',
pkifname = '$CFTPKU',
pkipassw = 'CFT',
state = 'ACT',
mode = 'CREATE'

After inserting the correct certificate in the PKI database, define the UCONF variable cg.ca_cert_id.
This value is required so that Transfer CFT knows which certificate to use when communicating with
Central Governance.
CFTUTIL uconfset id=cg.ca_cert_id, value='CG_CA'
Set UCONF values

Use the Central Governance installation values for the following UCONF settings. Transfer CFT uses
these values to identify Central Governance.
l cg.host
l cg.port
l cg.mutual_auth_port
l cg.shared_secret
Use the format:
CFTUTIL uconfset id=cg.host, value=<host_value>
Enable Central Governance
CFTUTIL uconfset id=cg.enable, value=yes
Register
Start the Transfer CFT Copilot to trigger an automatic registration with Central Governance.
You can check in the Central Governance Product List to confirm that the registration was
successful.
On Transfer CFT z/OS
Use compliant characters for the z/OS shared secret

When setting the Central Governance "shared secret" during a Transfer CFT z/OS installation,
translation issues may occur if you use certain characters. For example, if you enter !SECRET (using
code page IBM-1147) the shared secret is translated to §SECRET during the Central Governance
registration. Therefore, you must use compliant characters in the shared secret value when working
in a z/OS environment.

Verify the UCONF setting

Prior to the registration, you must ensure that the JCL CFTMON
(copilot.misc.cftstart.enable = Yes) is configured to match the jobname or the STC name
used to launch Transfer CFT.
Use compliant characters for the z/OS shared secret
Use a proxy server between Transfer CFT and Central

Governance
To use a proxy server between Transfer CFT and Central Governance, set the following Transfer CFT
proxy parameters prior to registering with Central Governance:
l cg.proxy.in.host
l cg.proxy.in.port
l cg.proxy.in.login
l cg.proxy.in.password
See UCONF: Central Governance options for details.
Connect to a different Central Governance

system
If Transfer CFTwas previously registered on a Central Governance system but you now want to
register it on a different one, perform the steps in Manually activate connectivity and as a final step,
prior to starting Copilot, reset the Central Governance registration id.
CFTUTIL uconfunset id=cg.registration_id
Use former configuration objects

In Central Governance you can use the Legacy Flows feature to view and use an imported
configuration. For more information, please refer to the Central Governance documentation.
View managed features

After successfully upgrading and activating Central Governance connectivity, you can manage the
following Transfer CFT features from Central Governance. The "Supported but not configurable"
column lists features that you can retain, though you cannot manage them from the Central
Governance interface.

Feature Manage using Supported but not

Central Governance configurable using
Central Governance
Folder monitoring yes yes
Multi-node architecture no yes
CRONJOB no yes
Exits no yes
Network features
IPv6 yes yes
pTCP (UNIX/Windows only) yes yes
UDT (UNIX/Windows only) yes yes
SOCKS no yes
Heartbeat embedded yes
Interoperability
Secure Relay no yes
TrustedFile no yes
PassPort AM embedded no (*)
PassPort PS no yes
Sentinel embedded yes
Composer no no
Protocols
PeSIT yes yes
ODETTE no yes
EBICS no yes
* If you perform a migration or upgrade from a previous version, you must migrate your PassPort
AM.

Post-migration procedure
Post manual migration or auto import

If you performed an install and auto import or a manual migration, you must manually import
compiled objects and exec scripts from the old configuration. There are no Transfer CFT commands
to import these compiled objects and exec scripts, and they are not included in the auto import
process.
Note After completing an upgrade or a migration procedure, you must update to the most recent
SP.
Compiled objects: APIs and Exits

To manually migrate your API and exit binary files after migrating, copy your program's source code
to the new Transfer CFT 3.3.2 runtime directory and compile them.
1. Copy the API source code to <new_Transfer CFT_3.3.2_installation_
dir>/runtime/src/capi and compile.
2. Copy the Exit source code to <new_Transfer CFT_3.3.2_installation_
dir>/runtime/src/exit and compile.
Exec scripts
Copy the exec scripts to <new_Transfer CFT_3.3.2_installation_dir>/runtime/exe. It is important
that you update any paths that you were using in the exec scripts to reflect the new installation
directory.
Post-manual migration only
Migrating UCONF parameters from a previous Transfer

CFT version
You must manually migrate UCONF parameters for versions prior to Transfer CFT 2.5.1. The UCONF
configuration replaces the following configuration files:
l Sentinel configuration file (trkapi.cfg, trkapi.conf, and so on...)
The parameters in the Sentinel file are integrated in UCONF as sentinel.FORMER-PARAMETER-
NAME. For example, TRKTNAME becomes sentinel.TRKTNAME.

l Copilot ini file ( copconf.ini)
This file no longer exists. All former Copilot parameters are named
copilot.SECTION.PARAMETER-NAME in the UCONF interface. For example, the parameter
ServerPort, located in the general section, is now copilot.general.serverport.
l The profile file, formerly ENV_CFT or cft.ini, now uses UCONF to set the environment variables.
Post upgrade
If you performed an upgrade, you need only recompile your APIs and Exits.

Uninstall
5
This topic describes how to uninstall Transfer CFT. If you uninstall a Transfer CFT, you will lose the
complete Transfer CFT c onfiguration. To avoid this, save your environment (sample, exit, …) before
removing the Transfer CFT.
About uninstalling in Windows

The same user that did the initial installation (or at least the same type of user) must start the
uninstall procedure.
System Account).
<domain>\<username>
or the <hostname>.
Example
Local user: user1
.\user1
<hostname>\user1
Network user: user2
<domain_name>\user2
Before you begin uninstalling, you must stop the servers you want to uninstall.
1. You can run the installer in uninstall mode using GUI or console mode as follows. Enter:
If you installed products on Windows in service mode, the installer removes the service.
GUI mode
Windows: In the Start menu, select Axway Software > Axway [installation name] > Uninstall
Console mode

5 Uninstall
Windows:
l uninstall32.exe –m console
l uninstall64.exe –m console
3. Click Uninstall when prompted. A warning message displays; click Yes to continue with the
uninstall.
4. Click Next to see the uninstall summary, and Finish to exit.

Create a product deployment
package 6
A product deployment package in Transfer CFT is called an ExpressPackage.
The Express Package section describes how to create a reusable and distributable Transfer CFT
package to simplify and ease the task of installing and configuring Transfer CFTs on multiple servers
of the same architecture.
Note You can only install a Transfer CFT Express Package on the same platform as the one on
which it was generated. For example, a Transfer CFT Express Package that is generated on
linux-x86-64 can only be installed on a linux-x86-64 platform.
The procedure consists of:
l Installing a template Transfer CFT 3.3.2
l Configuring as required to meet your business needs
l Generating an Express Package that is based on the configured template
l Optionally customizing the Express Package
l Deploying and installing the Express Package
Install a template Transfer CFT

Begin by installing a Transfer CFT instance, and configure as required to meet your business needs.
This configured Transfer CFT serves as the template for the Express Package you are about to create.
Configure the:
l Static configuration, such as protocols (CFTPROT), networks (CFTNET), UCONF parameters,
and so on
l Partners (CFTPART, CFTTCP)
Note: If you create partners to export, DO NOT use the NSPART parameter in the CFTPART
definition. The target Transfer CFT will instead use the CFTPARM PART/NPART values.
l Flows (CFTSEND and CFTRECV)
l SSL certificates
l Processing scripts and EXITs
l Additional Axway components that you use with Transfer CFT, such as Central Governance
Note You can embed the contents of the CFTDIRRUNTIME/bin and CFTDIRRUNTIME/exec
directories in the generated Express Package.

6 Create a product deployment package
Generate the Express Package

To generate an Express Package from the template Transfer CFT:
1. Stop the Transfer CFT instance.
2. Navigate to the Axway installation directory of the template Transfer CFT, and run the Installer
in configuration mode.
Windows: The default Axway installation directory is C:\Axway.
Run the configure32.exe or configure64.exe executable depending on
the platform.
3. The Installer wizard displays. In the Welcome page select Next.

4. In the Configuration Type page, select Create an Express Package. Click Next to
continue.
5. Specify the file name of the Transfer CFT installation package that you used to install the
Transfer CFT template.
The package name format is Transfer_CFT_<version>_Install_<platform>_
BN<buildNumber>.zip.
6. Optionally, specify the file name of the service pack and/or patch to embed in the Express
Package.
o The format of the service pack name is Transfer_CFT_<version>_SP<SPNumber>_
<platform>_BN<buildNumber>.jar.
o The format of the patch name is Transfer_CFT_<version>_
Patch<PatchNumber>_<platform>_BN<buildNumber>.jar.
7. Enter the path to the location where you want the new Express Package to be saved once
generated.
9. Select the configuration elements that you want to include in the Express Package, such as the
partners and parameters database, the UCONF parameters, and the local PKI database. Click
Next to continue.
Note 1: If you are using Central Governance, you should only include the UCONF parameters
and the local PKI database. The other configuration elements are deployed by Central
Governance.
Note 2: If you selected the auto import feature during the Transfer CFT template installation,

you can only include the CFTDIRRUNTIME/bin and CFTDIRRUNTIME/exec contents.
10. In the Configuration confirmation page, click Configure to generate the Express Package.
Results
The Express Package, Transfer_CFT_<version>_ExpressPackage_<platform>_
<timestamp>.zip, is generated and located in the directory you selected in the previous steps.

Customize the Express Package

You can customize the Transfer CFT Express Package prior to deploying and installing it. The
Transfer CFT Express Package is nearly the same as the Transfer CFT Install package, the only
difference being the additional ExpressPackage directory. If you are not customizing the Express
Package (for example the installation directories), you c an skip this section.
The ExpressPackage directory contains the:
l data directory: This directory contains the data exported from the Transfer CFT template.
o bin directory: This directory contains all files retrieved from CFTDIRRUNTIME/bin.
o exec directory: This directory contains all files retrieved from CFTDIRRUNTIME/exec.
o pki directory: This directory contains all exported certificates.
o cft-parm.cfg: This file contains all of the parameter database objects ( CFTPARM,
CFTCAT, CFTLOG, CFTSEND, CFTRECV, and so on).
o cft-part.cfg: This file contains all of the exported Transfer CFT p artner database
objects (CFTPART, CFTTCP, and so on).
o cft-cftparm.cfg: This file contains only the CFTPARM objects to be imported during
the Express Package installation.
o cft-uconf.cfg: This file contains any UCONF parameters that were configured in the
template Transfer CFT.
o cft-pki.cfg: This file contains all of the PKICER commands to be executed during the
Transfer CFT Express Package installation.
l expressPackage.properties: This file contains all of the installation parameters that can be
overwritten. All parameters are documented within this file. To personalize any of these
parameters, uncomment the respective line and add the new value.
l install executable: The executable to install the Express Package.
To customize the Express Package before deploying it:
1. Unzip the package to a temporary directory, for example tempdir.
Windows
Unzip the package using your favorite zip tool.
2. Edit the expressPackage.properties file located in the ExpressPackage directory, for
example tempdir/ExpressPackage. Customize installation parameters as needed.

3. Rezip the package.
Windows
Browse to the ExpressPackage directory, and zip all contained files into a package
named Transfer_CFT_<version>_ExpressPackage_<platform>_
<timestamp>_new.zip (excluding the original zip file).
Example: Install Transfer CFT in a different directory

In this example, the Transfer CFT template was installed in the /home/cft/Axway/Transfer_CFT
directory.
To install Transfer CFT in a different directory on the target server, edit the
expressPackage.properties file, uncomment, and set the Axway_InstallDir, CFT_InstallDir, CFT_
RuntimeDir , CFT_Crypto_KeyFilename, and CFT_Crypto_SaltFilename parameters.
Axway_InstallDir = /opt/Axway
CFT_InstallDir = /opt/Axway/Transfer_CFT
CFT_RuntimeDir = /opt/Axway/Transfer_CFT/runtime
CFT_Crypto_KeyFilename = /opt/Axway/Transfer_
CFT/runtime/data/crypto/crypkey
CFT_Crypto_SaltFilename = /opt/Axway/Transfer_
CFT/runtime/data/crypto/crypsalt
Example: Install Transfer CFT in the home directory of

different user accounts
You can install the Transfer CFT on a target server in the home directory of different user accounts in
a generic way using environment variables. Edit the expressPackage.properties file, uncomment,
and set the Axway_InstallDir, CFT_InstallDir, and CFT_RuntimeDir parameters as follows.
WINDOWS
In this example, the Transfer CFT template was installed on server0 by the user account test, in the
C:\Users\test\Axway\Transfer_CFT directory.
Axway_InstallDir = %USERPROFILE%\axway
CFT_InstallDir = %USERPROFILE%\axway\cft
CFT_RuntimeDir = %USERPROFILE%\axway\cft\runtime

Install the Express Package

Note Windows only. If you have implemented a firewall, deactivate the firewall prior to
installation.
To deploy and install the Express Package:
1. Upload the generated Transfer_CFT_<version>_ExpressPackage_<platform>_
<timestamp>.zip file to the target server.
2. Unzip the package.
3. Browse to the ExpressPackage directory located within the unzipped package.
4. Run the install executable. On Windows platforms (7/2008/2012) you must run the install

executable with administrator rights.
Note If you run the install without an argument, the install executable uses the

expressPackage.properties file, in the ExpressPackage directory, as the customization file.
In command line you can specify a different file name using the following OS-specific
syntax.
Windows
install.exe <file name>
Limitations
l Transfer CFT Express Package does not support cluster mode installations.
l Transfer CFT Express Package cannot embed a Transfer CFT upgrade pack.

Troubleshooting
7
Troubleshoot installation and registration
This section lists some possible post-installation issues along with corresponding corrective actions
when applicable. If corrective actions do not remedy the issue, check the Support tools section for
more information, or contact support at support.axway.com.
Copilot server issues
Copilot doesn't start

l Check that the port is not already used by another application.
l Close all active sessions, use the syntax: copstop -f
l Check that there are no orphan "cop*" processes. If there are, manually kill these processes.
Central Governance
Troubleshoot the registration

If Copilot starts, but the Transfer CFT either does not display in the Central Governance Product
List or registers in error:
l Verify the Central Governance IP address (or FQDN) used in the Transfer CFT configuration.
l On the computer running Transfer CFT, check that you can reach Central Governance at the IP
address used in the Transfer CFT configuration.
l Check that the Transfer CFT appears in the Central Governance logs. If not, typically this is
because the Transfer CFT is unable contact Central Governance.
l In Central Governance check Administration > Services to ensure that Central Governance
is correctly started.
l Verify the shared secret for Central Governance used in the Transfer CFT configuration.
Note See the Central Governance documentation for additional information and details.

7 Troubleshooting
Registration fails after installing in service mode when

using a firewall
Windows only, firewall enabled
Transfer CFT cannot register in Central Governance when installing Copilot in service mode.
l Preventive measure: Deactivate the firewall to perform the registration.
l Workaround: If you encounter this error, perform the following steps to register:
1. Stop the Copilot Windows service.
2. Manually start the service in a DOSBOX to register.
3. Accept the authorization from the Windows firewall.
Re-register with Central Governance

When Central Governance sends the SSL certificates to Transfer CFT, the uconf:cg.registration_id
parameter is set to a positive integer. If an error occurs, the registration process ends in error. To
repeat the registration, perform the following steps:
1. Stop Transfer CFT.
2. Stop Copilot.
3. Set the uconf:cg.registration_id to its default value (-1) using the command:
CFTUTIL uconfunset id=cg.registration_id
4. Start the Transfer CFT Copilot. Copilot starts the registration process.
More information
For more information on Central Governance, refer to the Central Governance1.1.3 documentation.
Transfer CFT server
Cannot start my Transfer CFT

l Check your Transfer CFT log in Central Governance.
l From the local Transfer CFT runtime, try to manually start the server. If you cannot manually
start the server, refer to Support tools in the Transfer CFT User Guide.
Applying a license key

Windows

7 Troubleshooting
You need to apply a valid license key to Transfer CFT in the following situations:
l You perform an initial Transfer CFT installation.
l To replace an expired license key (typically after a year).
Obtain a license key

1. Install Transfer CFT. You can install Transfer CFT without a license key, and enter the key
afterward.
2. After completing the installation, or for an existing installation, use the c ommand cftutil
about to retrieve your system information.
3. Contact the Axway Fulfillment team at the appropriate email address, and provide the hostname
and system information.
l For a US key, contact: fulfillment@us.axway.com
l For an EMEA or APAC key, contact: product.key@axway.com
Apply a license key

Normally you enter the key that you received from the Axway Fulfillment team during the
installation process. However, to apply the license key at a later date, enter the key(s) in
the indirection file, which is referred to in the CFTPARM KEY parameter. See the
KEY parameter for an example and details.
l The file can contain one or multiple license keys, but it must have one key per line.
l On start up the first valid key is used.
Multi-node keys
As of Transfer CFT 3.3.2 SP2, you can use a single key for a multi-node installation. To use
a single key for multiple hosts, either:
l The hostname defined for the key matches the hostname of one of the hosts that
composes the multi-node instance
For example, if you have 2 hosts and 4 nodes, you only need one key that matches one
hostname (or no defined hostname).
If you are using a Transfer CFT 3.3.2 prior to SP2, multi-node architecture requires:

7 Troubleshooting
l One key per node, and if there is more than one host you require at least one valid key
per host
For example, if you have 2 hosts and 4 nodes, you require 4 keys with at least one key per
host. Possible key combinations could be:
l 2 keys that are configured to reference the first host, and the 2 other keys configured
to reference to the second host
l 3 keys that are configured to reference the first host, and 1 that is configured to
About command
Use the CFTUTIL utility to execute the about command to display key and general system
information as demonstrated in this example.
CFTUTIL about
…
Host information :
* model =
* hostname = ITEM-AX31614
* sysname = Windows
* machine = AMD_X8664
* version = 6.2.9200
* release =
* distrib =
Support tools /contact Support

This section describes the tools available to help you collect information and contact support if you
are unable to troubleshoot an error or issue.
Accessing the Axway Support site

In the Axway Sphere Support web site, click to select Contact us for the email address and phone
number of your nearest Axway support site.

7 Troubleshooting
Opening a Support case

Before contacting Customer Support, we suggest that you start by using the Axway online patch
library to see if there is a patch available for your problem, or by searching for a solution in the
Knowledge Database. If you still need to contact Support, have the following information available
if possible:
l Product version
l Operating system
l cft_support
To submit a Support request, you can do the following:
l Submit and track your request through the Axway Support Web site support.axway.com.
l Each time you submit a support request, that request is assigned a unique number. Use this
specific number when you contact Customer Support concerning that case.
l You must have a user account to submit a Support request.
Using cft_support
The cft_support tool collects all of the needed information from the customer's Transfer CFT
installation environment, including the static configuration (PARM/PART), Unified Configuration
parameters (UCONF), catalog information, communication media file status (CFTCOM), log files,
execution environment (variables), disk space, and so on. This information is then packaged into a
archive file called cft-support-<date>(.tar.gz|.zip).
Note When using the cft_support tool on other Operating Systems, refer to the OS-specific
guide for the correct syntax.
Using Copilot
From the Copilot UI, click the debug icon. The report is saved in the Transfer CFT runtime
directory, after which you are prompted to download the report to your desktop.
Using command line

In command line, enter: cft_support collect [options]
Options:
l --help: Display this help and exit.
l --cat-filter: Filter the CFTUTIL LISTCAT output. See LISTCAT, or enter CFTUTIL HELP
CMD=LISTCAT, to view available parameters.
l --cat-debug-filter: Filter the CFTUTIL LISTCAT CONTENT=DEBUG output. This option overrides
--cat-filter.

7 Troubleshooting
l --no-core-analysis-gdb: Do not use gdb to analyze the cores. Unix only
l --no-core-analysis-dbx: Do not use dbx to analyze the cores. Unix only
Examples
Only collect information for a given transfer:
cft_support collect --cat-filter="IDTU=A0000001"
Collect information for all transfers in error for a given partner:
cft_support collect --cat-filter="DIAGI=ERROR, PART=PARIS"
Collect transfer information related to a given IDF for all transfers in a brief LISTCAT, and only those
transfers in error in a debug LISTCAT:
cft_support collect --cat-filter="IDF=BIN" --cat-debug-filter="IDF=BIN,

DIAGI=ERROR"
The command CFTSUPPORT executes a program located in CFTPGM. This program generates a tar
file in the IFS environment with all the necessary information for Axway.
Note CFTSUPPORT is currently not supported with an independent ASP (IASP).
Activating Transfer CFT traces when a problem occurs

during the transfer
Note ATM traces are available only when using Transfer CFT Local Administration. However
Central Governance managed Transfer CFT is the recommended version.
Transfer CFT traces are managed by the Advanced Trace Manager ( ATM) component. ATM is a
problem resolution assistance tool that is used to save Transfer CFT information, and retrieve
previously saved Transfer CFT information.
You may need to initiate tracing in order to assist Transfer CFT Support service if an error occurs.
The Transfer CFT Support service can analyze the traces to better help you resolve the issue.

Operations
8
About Windows operations
Transfer CFT Windows specific operations

This section describes functioning and operations in a Windows environment, including:
l Operating the product
l Specific system functions
l Programming interfaces
l Transfer CFT c lient/server architecture
The information in the Windows operations section may be supplemented, corrected, or even
contradicted by the README.TXT file or the Release Notes supplied with the product. The
README.TXT file and Release take priority in this case.
Product presentation
Transfer CFT can operate both as client and/or as server. The number of simultaneous transfers that
Transfer CFT can support is defined by the start-up key. It is also limited by the properties of the
networks used. The TCP/IP network is supported.
About Windows operations
Transfer CFT Windows specific operations

This section describes functioning and operations in a Windows environment, including:
l Operating the product
l Specific system functions
l Programming interfaces
l Transfer CFT c lient/server architecture
The information in the Windows operations section may be supplemented, corrected, or even
contradicted by the README.TXT file or the Release Notes supplied with the product. The
README.TXT file and Release take priority in this case.

8 Operations
Product presentation
Transfer CFT can operate both as client and/or as server. The number of simultaneous transfers that
Transfer CFT can support is defined by the start-up key. It is also limited by the properties of the
networks used. The TCP/IP network is supported.
Transfer CFT communication systems

This topic presents basic information about the hardware devices and the software for each of the
communications systems. Direct contact with the distributor ensures that you have an exhaustive
and accurate list of devices than can be used with Transfer CFT Windows.
Transfer CFT Windows can use the TCP/IP network as its communications system.
Transfer CFT provides two options:
EICON option
This option was validated with the EICON card resident on the same machine on which Transfer CFT
Windows executes.
EICON products used for validation were:
l On Windows:
o C21 card or a S51 card
o EICON WAN services for Windows (V3R4)
o Eicon WAN Adapters
Refer to the operations to perform prior to your first start-up with an EICON card, in Running CFT for
the first time.
CAPI option
This option works with all types of cards. It has been validated with a CAPI interface card resident on
the same machine on which Transfer CFT Windows is executed, under all operating systems.
The products used for validation are:
l DIVA card from EICON, or GAZEL card
l Corresponding CAPI d river
Refer to the operations to perform prior to your first start-up with ISDN-CAPI cards, in Running CFT
for the first time.
TCP/IP network
Transfer CFT can be based on the TCP/IP layer supplied as standard by Windows.
When it operates in TCP/IP, Transfer CFT can use any type of link that c an be implemented via the
WINSOCK interface.

8 Operations
Refer to the operations to perform prior to your first start-up in TCP/IP, in Running CFT for the first
time.
Applying a license key

Windows
You need to apply a valid license key to Transfer CFT in the following situations:
l You perform an initial Transfer CFT installation.
l To replace an expired license key (typically after a year).
Obtain a license key

1. Install Transfer CFT. You can install Transfer CFT without a license key, and enter the key
afterward.
2. After completing the installation, or for an existing installation, use the c ommand cftutil
about to retrieve your system information.
3. Contact the Axway Fulfillment team at the appropriate email address, and provide the hostname
and system information.
l For a US key, contact: fulfillment@us.axway.com
l For an EMEA or APAC key, contact: product.key@axway.com
Apply a license key

Normally you enter the key that you received from the Axway Fulfillment team during the
installation process. However, to apply the license key at a later date, enter the key(s) in
the indirection file, which is referred to in the CFTPARM KEY parameter. See the
KEY parameter for an example and details.
l The file can contain one or multiple license keys, but it must have one key per line.
l On start up the first valid key is used.
Multi-node keys
As of Transfer CFT 3.3.2 SP2, you can use a single key for a multi-node installation. To use
a single key for multiple hosts, either:
l The hostname defined for the key matches the hostname of one of the hosts that
composes the multi-node instance

8 Operations
For example, if you have 2 hosts and 4 nodes, you only need one key that matches one
hostname (or no defined hostname).
If you are using a Transfer CFT 3.3.2 prior to SP2, multi-node architecture requires:
l One key per node, and if there is more than one host you require at least one valid key
per host
For example, if you have 2 hosts and 4 nodes, you require 4 keys with at least one key per
host. Possible key combinations could be:
l 2 keys that are configured to reference the first host, and the 2 other keys configured
to reference to the second host
l 3 keys that are configured to reference the first host, and 1 that is configured to
About command
Use the CFTUTIL utility to execute the about command to display key and general system
information as demonstrated in this example.
CFTUTIL about
…
Host information :
* model =
* hostname = ITEM-AX31614
* sysname = Windows
* machine = AMD_X8664
* version = 6.2.9200
* release =
* distrib =
Running Transfer CFT for the first time

The elements and tasks required to start Transfer CFT for the first time include:
l Set the environment
l Start Transfer CFT using a command
l Shut d own Transfer CFT using a command
l Start or stop Transfer CFT via a user interface

8 Operations
l Service mode
l Start the CFTW desktop window
Set the environment

After installing Transfer CFT , but before starting Transfer CFT you should:
l Execute the profile.bat in the Transfer CFT runtime directory to define environment
variables.
l Create a new set of Transfer CFT working files, parameters, partners, catalog, communication
file, logs, use the sample configuration files cft-tcp.conf and cft-tcp-part.conf in the
runtime\conf directory. You can configure these during the product installation or
manually after installation.
l Use cftinit <configuration_file> > and/or cftupdate to interpret the parameter and
partner files.
cftinit conf\cft-tcp.conf
cftupdate conf\cft-tcp-part.conf
or
cftinit conf\cft-tcp.conf conf\cft-tcp-part.conf
Caution These commands generate an initial configuration by creating the configuration files.
Any previous configurations, and any data in the communication file, catalog, or log
files will be lost.
Sample file details
l cft-tcp.conf: Contains PARM object definitions (PARM, CAT, COM, LOG, ACCNT, PROT,
SEND, RECV,...etc.).
l cft-tcp-part.conf: Contains partner definitions (CFTPART, CFTTCP, CFTSSL).
Delivered partners are:
l PARIS - NEW YORK
l LOOP
l LOOPSSL0
Start and stop commands

Version 2.7.1 and higher Version 2.7.0 and lower
cft start cftstart

8 Operations
cft stop cftstop
cft status cftstatus
cft force-stop cftstop -kill
cft force-stop -kill cftstop -forcedkill
Note The cftstart and cftstop commands, from version 2.7.0 and earlier, are redirected to

the standardized commands for continued compatibility.
Start Transfer CFT using a command

If you have not already done so, from the runtime directory execute the profile.bat to set the
Transfer CFT environment. Then in the same dos session, enter the command: cft start
Shut down Transfer CFT using a command

You can use one of the following methods to shut down Transfer CFT:
l CFTUTIL utility
CFTUTIL shut fast=no

or
CFTUTIL shut fast=yes
l cft utility using stop
cft stop
For more information, see the administrative commands in Manage the Transfer CFT server.
Start or stop Transfer CFT using a user interface

You can also use either Central Governance or the Transfer CFT Copilot UI to start or shut down
Transfer CFT.

8 Operations
Service mode
You can retroactively install Service mode for Transfer CFT. Use the Installer Configure mode to
install and uninstall the services for the Transfer CFT Server and Transfer CFT Copilot. To launch the
Installer in Configure mode, from the Start menu select Axway Software > Axway Transfer
CFT > Configure.
Start the CFTW desktop window

You can use the Windows utility cftw.exe to open a desktop window that displays the Transfer
CFT log messages and processes list in separate tabs. The cft start command automatically
launches this cftw.exe utility when the UCONF parameter cft.nt.start_graphmode is set to
Yes (default value).
Note When Transfer CFT is running as a service, you must have the service configured to
authorize desktop interaction, and you must manually launch the cftw.exe.
If Transfer CFTis not running, use the -wait option with cftw so that the utility waits for Transfer
CFT to start instead of exiting immediately.
cftw.exe -w
As of Transfer CFT v3.0.1, a second cftw UCONF parameter, cft.nt.cftw_display_log_
messages, is available. To display log messages in the cftw window, change the parameter setting
from No (default value) to Yes.
Running Transfer CFT for the first time

The elements and tasks required to start Transfer CFT for the first time include:
l Set the environment
l Start Transfer CFT using a command
l Shut d own Transfer CFT using a command
l Start or stop Transfer CFT via a user interface
l Service mode
l Start the CFTW desktop window
Set the environment

After installing Transfer CFT , but before starting Transfer CFT you should:

8 Operations
l Execute the profile.bat in the Transfer CFT runtime directory to define environment
variables.
l Create a new set of Transfer CFT working files, parameters, partners, catalog, communication
file, logs, use the sample configuration files cft-tcp.conf and cft-tcp-part.conf in the
runtime\conf directory. You can configure these during the product installation or
manually after installation.
l Use cftinit <configuration_file> > and/or cftupdate to interpret the parameter and
partner files.
cftinit conf\cft-tcp.conf
cftupdate conf\cft-tcp-part.conf
or
cftinit conf\cft-tcp.conf conf\cft-tcp-part.conf
Caution These commands generate an initial configuration by creating the configuration files.
Any previous configurations, and any data in the communication file, catalog, or log
files will be lost.
Sample file details
l cft-tcp.conf: Contains PARM object definitions (PARM, CAT, COM, LOG, ACCNT, PROT,
SEND, RECV,...etc.).
l cft-tcp-part.conf: Contains partner definitions (CFTPART, CFTTCP, CFTSSL).
Delivered partners are:
l PARIS - NEW YORK
l LOOP
l LOOPSSL0
Start and stop commands
cft start cftstart
cft stop cftstop
cft status cftstatus
cft force-stop cftstop -kill
cft force-stop -kill cftstop -forcedkill

8 Operations
Note The cftstart and cftstop commands, from version 2.7.0 and earlier, are redirected to

the standardized commands for continued compatibility.
Start Transfer CFT using a command

If you have not already done so, from the runtime directory execute the profile.bat to set the
Transfer CFT environment. Then in the same dos session, enter the command: cft start
Shut down Transfer CFT using a command

You can use one of the following methods to shut down Transfer CFT:
l CFTUTIL utility
CFTUTIL shut fast=no

or
CFTUTIL shut fast=yes
l cft utility using stop
cft stop
Start or stop Transfer CFT using a user interface

You can also use either Central Governance or the Transfer CFT Copilot UI to start or shut down
Transfer CFT.
Service mode
You can retroactively install Service mode for Transfer CFT. Use the Installer Configure mode to
install and uninstall the services for the Transfer CFT Server and Transfer CFT Copilot. To launch the
Installer in Configure mode, from the Start menu select Axway Software > Axway Transfer
CFT > Configure.
Start the CFTW desktop window

You can use the Windows utility cftw.exe to open a desktop window that displays the Transfer
CFT log messages and processes list in separate tabs. The cft start command automatically
launches this cftw.exe utility when the UCONF parameter cft.nt.start_graphmode is set to
Yes (default value).
Note When Transfer CFT is running as a service, you must have the service configured to
authorize desktop interaction, and you must manually launch the cftw.exe.

8 Operations
If Transfer CFTis not running, use the -wait option with cftw so that the utility waits for Transfer
CFT to start instead of exiting immediately.
cftw.exe -w
As of Transfer CFT v3.0.1, a second cftw UCONF parameter, cft.nt.cftw_display_log_
messages, is available. To display log messages in the cftw window, change the parameter setting
from No (default value) to Yes.
Transfer CFT user interfaces

Transfer CFT features the following user interfaces:
l CFTUTIL - a command line utility that can be used after installation in the following modes:
o Command mode
o File interpretation mode
o Interactive line mode
l Transfer CFT Copilot UI Transfer CFT Copilot UI - a graphical user interface that enables users to
manage and use Transfer CFT via a series of windows and icons
Using either of the user interfaces you can c reate the working environment and configure Transfer
CFT as follows:
l Create and delete p arameter, partner, catalog, log, and account files (Transfer CFT must be
stopped)
l Modify parameters
l View parameter, p artner, catalog, log, and account files
l Send commands to Transfer CFT
Start Transfer CFT from the user interface

To start the Transfer CFT from the user interface:
1. Start the UI server. You must have appropriate rights to log on the Transfer CFT UI server.
2. Launch the Transfer CFT UI.
3. Enter the login/password.
4. Start the Transfer CFT. You must have appropriate rights to start the Transfer CFT.
For more information, refer to Transfer CFT Administration.
Related topics

8 Operations
l Define user rights
l Starting/stopping Transfer CFT
l Starting/stopping the GUI
Defining user rights Windows

Before you can start Transfer CFT from the Transfer CFT Copilot server, the Copilot server must be
started. Additionally you will need rights to log on to this server. The overall process requires that
you:
l Define rights before starting the Transfer CFT UI server (Copilot)
l Define rights before logging on the Transfer CFT UI server (Copilot)
l Define rights before starting Transfer CFT
l Define a domain user
l Define folder rights
l Define system user access
Define rights before starting the Transfer CFT UI server

To be able to start the Transfer CFT Copilot server you must give each Windows user read and write
rights for the Transfer CFT installation folder as follows:
1. Right-click the Transfer CFT program folder.

2. Select Properties.
3. In the Properties window, select the Security tab.
4. In the Security tab, select the user and grant the user read and write rights. Click OK.
Additionally, if you want to start the Transfer CFT GUI server as a service with a user account, instead
of the local system, it must have Log on as a service authority.
1. In a dos command window, type secpol.msc to open the Local Security Policy window.
2. Select Security Settings > Local Policies > User Rights Assignment.
3. Double-click Log on as a service.
4. Click Add user or group and define.
You can opt to control the file-access permissions and the batch execution environment by setting
the UCONF copilot.misc.createprocessasuser identifier as follows:
l no: Any user who logs on the Transfer CFT GUI server will have their processes identified as the
user who started the Transfer CFT Copilot server.
l yes: Any user who logs on the Transfer CFT GUI server will have their processes identified as
their own.

8 Operations
Define rights before logging on the Transfer CFT UI

(Copilot) server
copilot.misc.createprocessasuser PassPort Rights to define
AM
status
Not activated No need to set rights. All
no Windows users can log on to the
Transfer CFT GUI server.
no Activated If PassPort AM is activated, you

must use a PassPort AM user to
log on. Check if the AM user has
the rights to manage Transfer
CFT.

8 Operations

AM
status
yes Not activated The Windows user who is going

to log on the Transfer CFT UI
server, must have read and write
rights for Transfer CFT install
folder.
Some user rights must be
assigned to the user who
launched the Transfer CFT UI
server to permit other Windows
users to log on. This is true
except if it is the local system
account when working in the
service mode. The user rights to
assign are:
l Adjust memory quotas for a
process
l Impersonate a client after
authentication (only on
Windows 2008)
l Replace a process level
token
l Create a token object
To define user rights:
1. In a dos command window,
enter lusrmgr.msc to open
the system users list. Check
available users.
enter secpol.msc to open
the Local Security Policy
window.
3. Select Security Settings >
Local Policies > User Rights
Assignment.
4. Double-click the required
right.
5. Click Add user or group and
define.

8 Operations

AM
status
6. Close and re-open the
Windows session to take
into account the
modifications.

8 Operations

AM
status
yes Activated Some user rights must be

assigned to the user who starts
the Transfer CFT UI server to
allow other Windows users to
log on, unless it is the local
system account working in
service mode. The user rights
are:
l Adjust memory quotas for a
process
l Impersonate a client after
authentication (only on
Windows 2008)
l Replace a process level
token
type lusrmgr.msc to open
the system users list. Check
available users.
type secpol.msc to open the
Local Security Policy
window.
3. Select Security Settings >
Local Policies > User Rights
Assignment.
4. Double-click the required
right.
5. Click Add user or group and
define.
6. Close and re-open the
Windows session to take
into account the
modifications.
Additionally, the user who wants
to log on the Transfer CFT UI
server must exist both in the

8 Operations

AM
status
Windows system and PassPort
AM. The Windows system
performs the user
authentication, and PassPort AM
checks the other rights.
Note: The PassPort user name is
case-sensitive.
Define rights before starting Transfer CFT

The Windows user who is going to log on the Transfer CFT GUI server requires read/write rights for
Transfer CFT install folder, defined as follows:
5. The same user name must exist in PassPort AM, and is allowed to manage Transfer CFT.
Note: The PassPort user name is case-sensitive.
Define domain user

Transfer CFT supports domain user accounts, which allows a service to use Windows service security
features.
File action executed for applicative users

To enable for file actions, check that the USERID user has access to the transfer destination
directory. To do this, copy the rights from the user's rights table and create a token object.
Post-transfer procedure executed for applicative users

To enable for post-transfer procedures, check that the USERID user has rights to execute end-of-
transfer procedures. To do this, copy the rights from the user's rights table and create a token
object.

8 Operations
Define folder rights

To be able to start the Transfer CFT server and the Transfer CFT GUI server (Copilot), you must give
each user read and write rights for Transfer CFT as follows:
Service mode login

If you are working in service mode, you must have Log on as a service authority.
3. Double-click Log on as a service.
Define system user access
System user enabled

If c opilot.misc.createprocessasuser=yes in UCONF , or Createprocessasuser=yes in [MISC], the user
starting the Transfer CFT Copilot server must do the following tasks to allow other users to log on.
Additionally, those users must exist in the Windows system users list.
l Adjust memory quotas for a process
l Simulate a client after authentication (only on Windows 2008)
l Replace a process level token
Procedure
1. In a dos command window, type lusrmgr.msc to open the system users list. Check available
users.
4. Double-click the required right.
PassPort AM is activated

8 Operations
If PassPort AM is active (am.type=PassPort in UCONF), the user must exist both in the Windows
system users list and PassPort AM users list. The Windows system user performs the authentication,
and PassPort AM performs the other rights checks.
Note The PassPort user name is case-sensitive.
System user deactivated with PassPort AM management

If c opilot.misc.createprocessasuser=no in UCONF, all system users have the right to log on.
l PassPort AM is activated
l If PassPort AM is active (am.type=PassPort in UCONF), you must be a defined PassPort AM user
to log on.
Note The PassPort user name is case-sensitive.
Related topics
About PassPort AM
UCONF parameters
Using system users Windows

This section describes Windows specific tasks to perform to enable system user authentication and
file system rights.
l Enable user authentication for Copilot on page 158
l Enable the file user rights (USERCTRL) on page 159
Enable user authentication for Copilot

This section describes how to define users for Transfer CFT Copilot server. The following information
applies except if you are using the local system account when working in service mode.
The user rights to assign are:
l Impersonate a client after authentication (only on Windows 2008)
1. In a dos command window, enter lusrmgr.msc to open the system users list. Check available
users.
2. In a dos command window, enter secpol.msc to open the Local Security Policy window.

8 Operations
6. Close and re-open the Windows session to take into account the modifications.
Some user rights must be assigned to the user who starts the Transfer CFT UI server to allow other
Windows users to log on, unless it is the local system account working in service mode.
The user rights are:
1. In a dos command window, type lusrmgr.msc to open the system users list. Check available
users.
Additionally, the user who wants to log on the Transfer CFT UI server must exist both in the
Windows system and Central Governance (or PassPort AM). The Windows system performs the user
authentication, and Central Governance (or PassPort AM) checks the other rights.
Note If using Central Governance, the user name is case-sensitive.
Enable the file user rights (USERCTRL)

Caution When USERCTRL=YES, access to UNC or mapped file drives (as opposed to local files)
are performed by the user who started Transfer CFT and not the owner of the transfer.
The Windows user who is going to perform transfers must have read and write rights for the files to
be transferred.
Some user rights must be assigned to the user who launched the Transfer CFT server to permit other
Windows users to perform transfers.
To assign user rights:

8 Operations
1. In a dos command window, enter lusrmgr.msc to open the system users list. Check available

users.
2. In a dos command window, enter secpol.msc to open the Local Security Policy window.
Specific network functions

This topic presents the TCP network supported by Transfer CFT Windows, and how to define the
network parameters.
Supported networks
TCP/IP is supported for Transfer CFT Windows.
You should consult the README file that is delivered with the product for more up to date
information. If there is a contradiction between the README file and this document, the README
file information takes precedence.
The network descriptions in this section are not guaranteed to be exhaustive. Additionally, the
logical key can limit the maximum number of transfers.
Defining network parameters

You implement network functions b y entering parameters into a single file, cftnet.cfg, located in the
Transfer CFT runtime\conf folder.
This file is made up of lines using the same syntax, each o f which corresponds to one function:
typenet<parameter>=value, where:
l typenet is an element taking on one of the following values:
l TCP: concerns A TCP/IP network process parameter
l <parameter> is an element containing the value of one of the specific parameters indicated in
this documentation . For more information see Environment Variables
l value is an element that takes on a value belonging to the parameter stated in field and
according to the documentation
Comments
To edit a line of comments in the file CFTNET.CFG, you can p lace the ‘#’ character in the first
column of this line.
Example

8 Operations
# this is a comment
Indication of the path for the cftnet.cfg file
Environment variable
CFTCFGPATH
Environment variable defining the sub-folder where the cftnet.cfg file is located. By default, Transfer
CFT searches for this file in the application default folder.
Transfer CFT must be stopped when the cftnet.cfg file is c reated or modified.
Define additional environment variables

Windows
When loading the Transfer CFT profile, files that are stored in the profile.d directory are also
executed, and all defined environment variables are then available in the current environment. This
enables you to use these variables in the Transfer CFT configuration or processing scripts.
How to define additional Transfer CFT environment

variables
1. In the %CFTDIRRUNTIME%/profile.d directory, create a new file with .bat as the suffix. In
this file, add your customized variables as follows. For example:
set MYVARIABLE01=TheVariableValue01
set MYVARIABLE02=TheVariableValue02
2. Execute the profile command.
About Windows-specific system functions

This section describes specific system functions when using Transfer CFT in Windows. It begins with
this topic, which introduces the use of environmental variables.
About environment variables

The operating system environment variables have an important role in Transfer CFT. In the standard
Transfer CFT parameter setting, these variables establish the correspondence b etween the logical
name and the physical name for all file names. The user uses the environment variable by prefixing
its name with the character ‘$’. The variable name that corresponds to the logical file name is
developed into the physical name.
Example
The environment variable [FULL_NAME] provides a definition to the operating system as follows:

8 Operations
FULL_NAME=C:\REP0\REP1\FILE.SUF which is used as follows by the Transfer CFT
parameterization: FNAME = $FULL_NAME
The implementation of a certain number of non-standard functions is shown in Windows specific
system functions. These functions are mostly system functions, but include some network
functions.
Using the SET command

The environment variables are set by the SET command, called beforehand in the same session as
the CFTMAIN or CFTUTIL executable.
Using the profile.bat file

You can set the equivalent environment variables using the profile.bat file located in the Transfer
CFT runtime folder. For example, the CFTNODEL setting would be: SET CFTNODEL=YES
Note For more information, see Environment variables and specific parameters.
About Windows-specific system functions

This section describes specific system functions when using Transfer CFT in Windows. It begins with
this topic, which introduces the use of environmental variables.
About environment variables

The operating system environment variables have an important role in Transfer CFT. In the standard
Transfer CFT parameter setting, these variables establish the correspondence b etween the logical
name and the physical name for all file names. The user uses the environment variable by prefixing
its name with the character ‘$’. The variable name that corresponds to the logical file name is
developed into the physical name.
Example
The environment variable [FULL_NAME] provides a definition to the operating system as follows:
FULL_NAME=C:\REP0\REP1\FILE.SUF which is used as follows by the Transfer CFT
parameterization: FNAME = $FULL_NAME
The implementation of a certain number of non-standard functions is shown in Windows specific
system functions. These functions are mostly system functions, but include some network
functions.
Using the SET command

The environment variables are set by the SET command, called beforehand in the same session as
the CFTMAIN or CFTUTIL executable.

8 Operations
Using the profile.bat file

You can set the equivalent environment variables using the profile.bat file located in the Transfer
CFT runtime folder. For example, the CFTNODEL setting would be: SET CFTNODEL=YES
Note For more information, see Environment variables and specific parameters.
Environment variables in Windows

This topic describes the environment variables and the specific parameters used in Transfer CFT
Windows. The ‘*’ character indicates that all networks are concerned.
l Terms annotated with (ve) are symbolic variables.
l In this list , the character ‘*’ indicates all networks, meaning that the key word must be set in
the CFTNET.CFG file for a given network.
Variables
l CFT_CSFN (ve)
l CFTAACCN (ve)
l CFTACCNT (ve)
l CFTALOG (ve)
l CFTCATA (ve)
l CFTCFGPATH (ve)
l CFTCOM (ve)
l CFTCONTCP (ve)
l CFTEXITTIME (ve)
l CFTINQA (ve)
l CFTLCKMAX (ve)
l CFTLOG (ve)
l CFTNMLOG (ve)
l CFTNODEL (ve)
l CFTNOFLUSH (ve)
l CFTPARM (ve)
l CFTPART (ve)
l CFTSFMCPY (ve) (Deprecated. Use uconf:cft.server.force_heterogeneous_mode.)
l CFTSRVNP
l CFTSRVTO
l CFTSRVTS
l CFTSUFX (ve)
l CFTTRCPATH (ve)

8 Operations
l CFTTRCSIZE (ve)
l TZ ou TZSET (ve)
Symbols and default files

This topic describes the symbols, default values, and variables used by Transfer CFT that are specific
to Windows operations and comprises the following subjects:
l Specific symbols
l Default files used by CFTUTIL
Specific symbols
The only FORG value supported for these systems is SEQ.
Subject Specific
value
Prefix to logical names $
Wild card character ?
Separator (volume) none
Prefix to symbolic variables &
Character introducing a file name sent to CFTUTIL in #
parameter form
Character introduced in the path_name of the fname +
parameter ( CFTRECV) from which a tree structure can be
created.
Default files used by CFTUTIL

Subject Default name
Parameters file $CFTPARM
Partners file $CFTPART
Catalog file $CFTCAT
Communication file $CFTCOM
Mailbox CFTMBX

8 Operations
Transferable files
This topic describes the Transfer CFT parameters that are specific to Windows concerning the
characteristics of the transferable file.
l Characteristics o f files automatically detected on transmission
l FTYPE values and FCODE values implicitly associated during transmission
l FTYPE and FRECFM values on receipt
Characteristics of files automatically detected on transmission
Parameter Automatically detected on transmission
FSPACE YES
FLRECL NO
FBLKSIZE NO
FRECFM NO
FTYPE NO
FTYPE values and FCODE values implicitly associated during transmission
FTYPE FCODE Type of sent file
' ' BINARY Binary
B BINARY Binary
V BINARY Binary file emulating locally a variable file format
T ASCII Text file with LF or CRLF as end-of-line separator
F ASCII Text file where the last character '1A' is transmitted (is
not c onsidered an EOF character)
O ASCII Text file with CRLF as end-of-line separator
X ASCII Text file with LF as end-of-line separator

8 Operations
FTYPE FCODE Type of sent file
J ASCII Stream text
Using stream text (J) allows a text type file to be sent
that contains records that exceed 32 KB. As opposed to
text type (FTYPE=T), stream text does not add an EOL
sequence (LF or CRLF) to the received file.
When using stream text (FTYPE=J), the sender and the
receiver must both have the FTYPE set to J. Setting only
the sender or receiver to FTYPE=J results in unexpected
content for the transferred file.
FTYPE = J refers to stream text.The stream text type allows sending a text file that contains records
that are larger than 32 KB. Unlike classical text types (T, O, X) the stream text type does not add an
EOL sequence (LF or CRLF) at the end of the received file.
Note FTYPE J is available in Transfer CFT Transfer CFT 3.0.1 SP7 (UNIX and Windows) and
higher.
FTYPE and FRECFM values on receipt
FTYPE FRECFM Type of received file
B F Binary fixed-length sequential file
B U/V Binary sequential file
V V Binary file emulating locally a variable file format
T F Fixed-length sequential text file with CRLF as end-of-
line separator
T U/V Variable length sequential text file with CRLF as end-
of-line separator
O F Fixed-length sequential text file with CRLF as end-of-
line separator
O U/V Variable length sequential text file with CRLF as end-
of-line separator
X F Fixed-length sequential text file with LF as end-of-line
separator
X U/V Variable length sequential text file with LF as end-of-
line separator

8 Operations
FTYPE FRECFM Type of received file
J U/V Variable length sequential text file with CRLF as end-
of-line separator
General operating functions

l Logical file names
l Using a definition file
Logical file names

Transfer CFT can use logical file names in order to designate the physical files and, if necessary, to
state the characteristics of these files. There are two methods of doing this:
l Using the operating system environment
l Using a file to d escribe the logical names
Users can choose one or other of these two methods. For the same Transfer CFT, certain logical
names can be described in the operating system and o ther in the logical names description file. A
certain number of logical names are defined as standard in Transfer CFT. This is the case for Transfer
CFT working files.
Note: The standard definition of the logical name for a Transfer CFT working file means that
regarding this logical name, there is no prior operation to perform before operating Transfer CFT.
If not, one of the following three operations needs to be performed b efore operating Transfer CFT:
l The CONFIG command o f CFTUTIL
l Sufficient screen p arameter setting in the Copilot interface
l Transfer CFT API COM command
Logical working files

Environment variables
The following table lists the logical names of files, and d efines the role.
Working file Logical Comment

name
Parameter CFTPARM Parameter file
Partner CFTPART Partner file
Catalogue CFTCATA Catalogue file

8 Operations
Working file Logical Comment

name
Communication CFTCOM Communication file
Log CFTLOG Log file
Log CFTALOG Alternate log file
Account CFTACCN Statistics file
Account CFTAACCN Alternate statistics file
Suffixes (1) CFTSUFX Suffixes file
Parameter SEC.INI System enabling file
Logical names CFTNMLOG Redefinition files
(1): see Recognizing file types
By default of definition for these logical names, the physical names c orrespond to the logical names.
Users who do not want to use the physical names of files by default, must redefine them in the
operating environment where CFTMAIN, CFTUTIL, Transfer CFT Navigator (Copilot) and the Transfer
CFT APIs execute. This operation must be performed BEFORE any Transfer CFT parameters are set.
When settings parameters for Transfer CFT, a user wanting to invoke a logical file name, must
systematically prefix the character string for the logical name with the "$" symbol.
Example of a logical name statement: fname = $CFTCOM
Using operating system environment variables
Because it is simple and flexible, this is the preferred method and is used whenever a straightforward
correspondence of logical name to physical name is sufficient.
When making re-definitions of this sort, users can use the environment variables provided by the
various operating systems. Quite clearly, the redefined names must be legal for the file system used
(FAT, NTFS, FAT32).
Examples of the using operating system environment variables:
SET CFTPARM=D:\MY_REP1\PARAMET
SET CFTPART=D:\MY_REP2\PARTENAI
SET CFTCATA=D:\MY_REP3\CATALOG
SET CFTCOM=D:\MY_REP4\COM.CFT
SET CFTLOG=D:\MY_REP5\LOG.JNL
SET CFTALOG=D:\MY_REP6\ALOG.JNL
SET CFTACCNT=D:\MY_REP7\ACCOUNT
SET CFTAACCN=D:\MY_REP8\AACCOUNT
SET CFTSUFX=D:\MY_REP9\SUFFIXE
SET CFTNMLOG=D:\MY_REP_10\NOMSLOG.SYS

8 Operations
Do not use suffixes for the physical p arameter and partner file names, except in the case where
Transfer CFT is operating in Client/Server with a UNIX Transfer CFT.
Note The CFTFILE command in CFTUTIL does not take into account any environment variables
set and corresponding to the Transfer CFT logical file names. You can overcome this
problem in a batch file by using c ertain operating system functions.
Example
The following command sets the CFTPARM environment variable to the value of TEST:
SET CFTPARM=TEST
The command file to be submitted contains the following line:
CFTUTIL CFTFILE type = param, fname = %CFTPARM%
When this command file is submitted, the operating system substitutes the string %CFTPARM% with
the string TEST. The command submitted to CFTUTIL is as follows:
CFTFILE type = PARAM, fname = TEST
Using a definition file

Use this method when you want to associate a logical name with a physical name and file attributes.
Since the content of these definitions is complex, refer to the samples supplied with the product.
The logical name of the file containing these definitions is CFTNMLOG.
For Transfer CFT Windows the only case where the use of a logical name definition file is necessary is
when you use the extraction tool for standard traces (ATM tool).
Example
The following line provides an example of the content of a line in the definition file.
TRCATM=CFTTRACE.BIN O=C,F=F,R=1024,T=B
In this example, the logical name TRCATM is g iven as the exit file in parameter to the Transfer CFT
trace extraction tool. The physical name CFTTRACE.BIN corresponds to the logical name TRCATM
and the following c haracteristics: contiguous file organization (O=C), fixed format (F=F), record
length 1024 characters (R=1024) and file is binary type (T+B).
Change of name or path of definition file

CFTNMLOG
By default the definition file is CFTNMLOG and it is located in the working directory.
To change the name and/or path of the definition file use the CFTNMLOG environment variable.

8 Operations
Communication media
l About the communication media
l Defining the CFT user name
l Adjusting the time and changing the date
l CFTUTIL shutdown timeout
About the communication media

Functionally, Transfer CFT is made up of two parts:
l The transfer monitor
l The user interface(s)
Transfer CFT uses a communication medium so that requests coming from the user interface can be
communicated to the monitor section.
Transfer CFT can use one of the two following communication media, either a:
l File
l Mailbox
By default, the communication medium used is the file with the logical name of $CFTCOM.
Note: Communication by mailbox is valid only for a standalone installation and between users of the
same group. That is, Transfer CFT/Windows has to be operating on the same machine and under a
user within the same group as the person sending the command.
Defining the CFT user name

The Transfer CFT user name is the name under which the Windows user is logged. Under certain
systems you can open a session without giving a user name. In this case, the Transfer CFT user name
is USERCFT.
Adjusting the time and changing the date

The time and date used or shown by Transfer CFT are those stated by the operating system.
By default the date changes at midnight, GMT. But as a general rule, if the country of use has been
indicated, the date changes at midnight local time. However in some infrequent and rather
specialized cases, the d ate can change at a different time (GM ± n).
TZ or TZSET

8 Operations
In general and to solve this problem the operating system provide a solution whereby users can
indicate the time zone in which he is located. This solution is supplied by the environment and
consists in general in setting an environment variable or a system parameter called TZ o r TZSET. For
additional information, consult the operating system documentation.
Transfer CFT takes this parameter into account, if it has been set.
CFTUTIL shutdown timeout

CFTEXITTIME
This function can remedy a problem that is produced in the MAILBOX c ommunication method. In
general, this problem occurs when a procedure executes automatically (end of transfer, …) using
CFTUTIL, and if the machine processor is loaded.
When this occurs, the Transfer CFT command that CFTUTIL uses to address to Transfer CFT is not
received, as if CFTUTIL had not been called. In fact CFTUTIL has been called and the command has
been posted, but since the machine is loaded, Transfer CFT c annot read the command posted by
CFTUTIL until it disappears. The disappearance o f CFTUTIL causes the command that has been
posted, but not y et received by the Transfer CFT, also to disappear.
By default, CFTUTIL waits for a maximum of 60 seconds before disappearing. To modify this time,
you define the CFTEXITTIME environment variable in seconds of wait time.
Example
SET CFTEXITTIME=120
This example causes CFTUTIL to wait a maximum of 120 seconds before disappearing.
Note This environment variable c an be used by all types of Transfer CFT interface: CFTUTIL,

Copilot and the Transfer CFT API application.
File management functions

l Managing file flushes
l Managing access conflicts to CFT working files
l Recognizing file types
l Sending a group of files
l Disabling the homogeneous mode

8 Operations
About file management functions
Managing file flushes

In certain circumstances, Transfer CFT performs an operation that forces a given file to be physically
written to the disk - a p hysical flush operations.
During the transfer, Transfer CFT implements two types of flushes:
l Flushes o n received files. These types of flush take place each time synchronization p oints are

received.
l Flushes o n the Transfer CFT catalog when synchronization points are received. See also the
CFTCAT UPDAT parameter.
These flush operations tend to secure transfers against risks c aused by serious hardware
malfunctions and unexpected mains power failures. Since this security behavior is time-
consuming,you may feel that such behavior is not warranted.
Deactivating the flush function

CFTNOFLUSH
You can modify one type of "flush", those implemented on received files, by setting the
CFTNOFLUSH environment variable. Set the environment variable to 1 or to 0 , depending on
whether you want to suppress or implement this type of flush.
For example, to deactivating the "flush" function:
SET CFTNOFLUSH=1
By default, transfer flushes continue to occur.
Managing access conflicts with Transfer CFT working

files
In certain o perating configurations, particularly in a Transfer CFT/Server – Transfer CFT/Client
architecture, the Transfer CFT working files are subject to frequent requests for simultaneous write
access; p articularly for the communication file. To manage access conflicts the file (or part of it) is
locked during the write operation. In other words, during the operation, only the process currently
writing has access to the file being written.
During this time the other "waiting to write" processes repeat their access requests to the operating
system.

8 Operations
CFTLCKMAX
You can modify the maximum number of attempts to access a file before a request fails (and a failed
write attempt message is sent) to the operating environment.
The CFTLCKMAX environment variable gives users the option of adapting the maximum number of
access attempts to their environment.
To access a file, Transfer CFT effects 50*CFTLCKMAX attempts.
The time between two attempts is calculated randomly between 0 and 500 msec.
By default, CFTLCKMAX=1
For example, if the defined environment is CFTLMAX=10, there are 10*50 attempts to access files
before a fail message is posted.
Recognizing file types

The Windows operating systems only handle files known as binary "stream" files. Therefore, with
these operating systems you do not know the type of data (binary, text, other) that a file contains.
An attempt to determine the type of data contained in a file by making a semantic study of its
content is not adequate. To remedy this, Transfer CFT proposes a special file type recognition
function using the suffix.
Change of name or path of suffix file
CFTSUFX
By default the suffix file is called CFTSUFX and it is located in the working directory.
To change the name and/or path of the suffix file use the CFTSUFX environment variable.
The data which enables Transfer CFT to ascertain a file type from its suffix is collected into a text file
of which the logical name is CFTSUFX ( see also the paragraph Logical File Names).
The CFTSUFX file is made up of lines that may consist of:
l A comment
l The definition o f a suffix, possible followed by a comment
A comment is any item of text beginning with the character ‘#’.
A suffix is defined in accordance with the following syntax:
<suffix of 1 to 3 letters>=<letter defining the file type>
Only characters supported by the operating system can be within the first 1-3 letters defining the
suffix. Wild cards, ‘?’ and ‘*’ cannot b e used.
There are three main file types:
l Binary files

8 Operations
Transfer CFT treats this type of file as any collection of b ytes. In this type of file, no binary
configuration takes any particular role. In the Transfer CFT parameterization, this type of file is
characterized b y the letter "B".
l Text files
Transfer CFT treats this type of file as a series of text lines each separated by the pre-defined control
code sequence CR-LF (0x0D – 0x0A).
This type of file may or may not end in the binary code 0x5A (ctrl Z) For all Transfer CFTs, a text file
is characterized by the letter "B".
l Variable files
In this type of file, records with binary contents are preceded b y 2 bytes, stating the length of the
record. This type of file can be g enerated, provided the parameterization is adequate, by Transfer
CFT o r by its COPYFILE utility. In the Transfer CFT parameter setting, this type of file is characterized
by the letter "V".
Adding types for the Transfer CFT/Server – Transfer CFT/Client architecture
In this architecture, you can operate Transfer CFT/Client Windows with a UNIX Transfer CFT/Server.
When you select a Transfer CFT/Server-client architecture, the Transfer CFT/Server and Transfer
CFT/Client elements should be specified in conjunction with Axway Sales Department.
There are certain differences in the way Transfer CFT manages text files b etween Windows machine
and UNIX machines. These should be taken into account to obtain satisfactory functioning.
In a UNIX text file, the lines are separated from one another by the single character "0x0A", while in
a Windows text file, the line separator is 2 characters "0x0D0A". When reading, this difference
causes no problem at all. When writing, users must specify to Transfer CFT the type of text file it
must create (UNIX text file, or Windows text file).
Transfer CFT provides you with two other letters, in addition to the letter "T", so that the text file
properties c an be given in full within a Transfer CFT server/client architecture, o perating UNIX and
Windows machines:
l O: forces Windows text type
l X: forces UNIX text type
The "T" type signifies native text (a Transfer CFT/Windows g enerates a readable text file in the
Windows environments, a Transfer CFT/UNIX generates a UNIX text file).
Files of type "text" are managed in the same way on Windows systems, which are considered by
Transfer CFT to be standardized environments.
The table below summarizes the letters indicating the type of file in the CFTSUFX file.
Letters defining a file type
Letter Type of file
B Binary file

8 Operations
Letter Type of file
O Text file (Windows text files)
V Variable file (in the Transfer CFT sense)
T Text file (native)
X Text file (UNIX)
Example of the content of the CFTSUFX file:
DOC=T #files with a ‘DOC’ suffix are text files.
T*=T #files with a suffix beginning with the letter ‘T’
#are text files.
EXE=B #files with an ‘EXE’ suffix are binary files.
V?R=V #files with a ‘V?R’ suffix are variable files.
Differentiation between upper and lower c ase
CFT_CSFN
Transfer CFT/Windows does not differentiate between upper and lower c ase in the suffix names
described in the suffix file. Such differentiation d oes take place if the environment variable CFT_
CSFN is set.
For example:
SET CFT_CSFN = 1
Sending a group of files

This section describes how to create a command to send a group o f files. To better understand this
section, refer to the following general group file information:
l Sending a group of files
l The FNAME a
nd WFNAME parameters in the CFTSEND and CFTRECV commands
A group file send request takes place implicitly when the value of the FNAME parameter for the
CFTSEND command has the following two characteristics:
l The first character is a surrogate character ‘#’
l The FNAME parameter states a folder, or contains meta-characters
Example
FNAME = #FIC*.*

8 Operations
A group of files can be sent in two different ways depending on whether the two partners are
standardized sites or not. The term of standardized sites means that the operating system of the two
Transfer CFT partners have identical file systems (for example, Windows is considered a standardized
system).
To indicate to a local Transfer CFT that it is not in standardized mode with a remote partner, the
SYST parameter in the CFTPART command should b e used. The SYST parameter makes it possible to
indicate to the local Transfer CFT that it and the remote Transfer CFT are on different operating
systems (not the same file system).
It is not necessary for the SYST parameter between standardized systems to contain data.
Sending a group of files in mixed mode

Transfer CFT detects that it is in a mixed environment because the SYST p arameter of the CFTPART
command contains data and is different from the local system.
In this mode, each file designated by the generic name of FNAME containing meta-characters is the
object of a special transfer.
This request to send generates as many posts in the catalogue as there are files to transfer.
Sending a group of files in standardized mode

The fact that Transfer CFT is sending a group of files in standardized mode allows the supplementary
functions described below to be implemented.
Transfer CFT detects that it is in standardized mode either because the SYST parameter in the
CFTPART command contains no data, or because, c ontaining data, the SYST parameter indicates
the same system as that o n which the local Transfer CFT is based.
In both cases, the two Transfer CFT partners implement a device which allows them to exchange
only a single (large) file in place of all the files designated by the generic FNAME of the sending
Transfer CFT.
This implementation is performed by calling a concatenation process external to Transfer CFT
(before the transfer for the transmitter) then a "de-concatenation" process (after the transfer for the
receiver).
These operations are performed on large and medium-sized systems, by standard tools within the
operative system (for example, the IEBCOPY utilities on the IBM host or tar on UNIX). This type of
standard tool does not exist on Windows. Therefore, the tools zip/unzip are provided in the Transfer
CFT Windows package.
These tools operate, either with several incoming files and one outgoing (this is the concatenation
called prior to the transmission), or with a single incoming and several outgoing files (this is the de-
concatenation called after reception).
Transfer CFT/Windows ensures that this function is "opened" b y calling different batches before
transmission by the transmitter and after reception on the receiver, as follows:
l The batch file CFTSVG01 is called before transmission and on the transmitter

8 Operations
This batch should constitute the file called WFNAME in the CFTSEND command. This is the file
which will actually be transmitted.
l The batch file CFTRST01 is called after reception and on the receiver
This batch should de-concatenate the file that has been received. This file takes the name stated in
the WFNAME parameter of the CFTRECV command.
The CFTSVG01 and CFTRST01 batch files must be located in the folder as default, when Transfer
CFT is executed.
These batch files are automatically called by the following parameters:
l For CFTSVG01:
o The 5th p arameter (%5) designates all the files to concatenate and corresponds to the
NFNAME of the CFTSEND command
o The 6th p arameter (%6) gives the name of the out file for the concatenation utility and
corresponds to WFNAME of the CFTSEND command
l For CFTRST01:
o The 5th p arameter (%5) gives the name of the in file for the de-concatenation utility
and corresponds to WFNAME of the CFTRECV command
o The 6th p arameter (%6) designates all the out files to concatenate and corresponds to
the NFNAME of the CFTRECV command
The other batch call parameters are unused, and therefore insignificant.
Parameter setting
To implement the transfer of a group of files in standardized mode, the conditions on the Transfer
CFT parameters are as follows:
l The parameter FNAME in the CFTSEND command is in the form of #<string>, in which
<string> indicates a folder or contains meta-characters
l The parameter WFNAME o f the CFTSEND command is a string indicating the name of the out
file for the concatenator on the transmitter
l The parameter WFNAME o f the CFTRECV command is a string indicating the name of the IN file
for the DE-concatenator on the receiver
This name does not need to be the same as that of WFNAME of the CFTSEND o n the transmitter
l The parameter FNAME o f the CFTRECV command indicates the full path of a folder name ending
with the ‘/’ character
Example
CFTSEND
.
FNAME = #FIC*.*,
WFNAME = &idtu.snd,
.

8 Operations
CFTRECV
.
FNAME = E:\CFTN.301\RECEPT\,
WFNAME = &idtu.rcv,
.
Note WFNAME must contain an extension (& idtu.rcv in this example) otherwise the ZIP or
UNZIP utilities add .zip to the file name. Certain operations in CFTSVG01.bat
CFTRST01.BAT cannot be performed then, and return the message "unknown or empty
file".
To use the above function between two different but standardized o perating systems (such as
Windows 7 for transmission and Windows Server for reception), check that the tool (or tool pair)
can be used in your operating system. In the example above, the de-concatenation on Windows
Server knows how to correctly restore on the Windows Server all of the files concatenated in
Windows 7.
However there is a problem when the two Transfer CFT partners are standardized and you simply
want to have recourse to the functions associated with transferring groups of files in mixed mode.
Disabling the homogeneous mode

Use the unified configuration parameter uconf:cft.server.force_heterogeneous_mode to enable
forced heterogeneous mode exchanges, and disable homogeneous mode.
Automated functions
This topic describes how to use a batch procedure in Transfer CFT Windows.
l Updating b atch procedures launched by Transfer CFT
l Using symbolic variables in batch files started by Transfer CFT
Batch procedures started by Transfer CFT

After a certain number of Transfer CFT events, such as transmissions, receptions, SWITCH
commands, for example, Transfer CFT can automatically start batch procedures. These are defined
in the parameters.
When these batch files are started, Transfer CFT generates a temporary b atch file name into which it
copies the content of the initial batch file, having resolved the symbolic variables which may have
been invoked. Once executed, by default, Transfer CFT deletes these temporary batch files.
Non-deletion of temporary batch files after execution

CFTNODEL

8 Operations
The CFTNODEL environment variable is able to stop Transfer CFT from definitively deleting the
temporary file, it is usually d eleted after it has been submitted and executed.
Updating batch procedures launched by Transfer CFT

When automatic procedures are started, Transfer CFT performs the following operations:
l Reads the batch file concerned
l Specifies and creates a unique name for the temporary file
The unique name for the temporary file is specified by specifying a p refix in the form of CFTnnnnn,
where nnnnn is a number between 0 and 9 9999. Each time a prefix is generated, the number nnnnn
is incremented b y 1. The following processes occur:
l Content of the b atch file in which the symbolic variables have been resolved is written into this
temporary file
l Temporary file executes
l Temporary file is deleted
If you have trouble using the batch procedures:
1. Start the batch file to be implemented manually and watch the effect this produces.
2. To observe the effect o f the substitutions by Transfer CFT of the symbolic variables, use the
CFTNODEL environment variable.
Using symbolic variables in batch files started by

Transfer CFT
Do not set an operating system variable d irectly into a batch file started by Transfer CFT.
If you do not take special precautions, there is a risk that a temporary file will be generated to
Transfer CFT, where it provokes an illegal operation when submitted to the operating system. Such
submission can be automatic o r manual, it is still an illegal operation.
You can still use environment variables, provided that they are set in a different batch file to that
started by Transfer CFT. The batch file started by Transfer CFT calls the batch file containing the
environment variable settings.
Example
/* BATCH started by CFT */

call pos_env
CFTUTIL SEND PART = &part, IDF = %IDF%
...
/* BATCH pos_env called by the batch file started by CFT */

SET IDF=TEST
...

8 Operations
Trace functions in CFT Windows

This topic introduces trace functions in Transfer CFT Windows. Trace functions are processes that
concern the system and network sections of Transfer CFT. These functions do not concern the
application traces implemented in common by all the existing Transfer CFT products and described
in the Trace function topics.
Automatic incident tracing

Transfer CFT automatically generates a trace when it detects a system o r network error that is fatal to
its operation. Some of these traces are informational. These traces are specific to the Transfer
CFT/Windows products.
Depending on the origin of the problem it has detected, these traces are recorded in one of the
following files:
Name of the Trace file Source of the problem
CFTSYSP.TRC Intermediate system section
CFTSYSS.TRC Specific Windows system section
CFTNET.TRC Network section
TCPCLI.TRC and TCPSRV.TRC TCP/IP network section
By default Transfer CFT automatically generates these trace files in the folder:runtime\run
folder
You can use UCONF to change the folder. For example:
CFTUTIL uconfset id=copilot.trace.trcfilename,value=c:\trc\copilot.trc
Only Axway Technical Support is able to interpret these traces. In a certain cases, Axway Technical
Support may request users to send the content of these files.
The maximum size and the location of these specific trace files can be defined.
Defining the size of specific trace files
CFTTRCSIZE
CFTTRCSIZE defines the maximum size of each of the trace files in megabytes.
If this value is set to 0, no trace file will be generated. If the environment variable has not been
defined, the maximum size of these files is 100 Mb. Once the maximum file size has been reached,
Transfer CFT/Windows saves the file as *b.trc and sets the file to 0.
Defining the location of specific trace files

8 Operations
CFTTRCPATH
CFTTRCPATH indicates the Transfer CFT/Windows the name of the folder where trace files discussed
in this section are generated.
For more information, read the section Specific Network Functions
Network traces
Refer to Specific Network Functions.
Setting protocol parameters
Setting up the TCP/IP layer

Before starting Transfer CFT with TCP/IP for the first time, you must setup your TCP/IP.
Procedure
1. Install and configure the TCP/IP layer.
2. In the SAMPLE folder, configure the PARMTCP.SMP sample file, with the key p arameter in
CFTPARM.
3. In the SAMPLE folder, configure the sample file PARMTCP.SMP. Configure the nspart and
nrpart parameters in CFTPARM, and the host parameter of the CFTTCP command.
4. Start the batch file ..\CFT\SAMPLE\RESETTCP.
5. Start CFTMAIN.
6. Check that CFTMAIN started correctly.
7. From a command prompt on a different Windows, and in the Transfer CFT root folder, enter the
command: > CFTUTIL SEND PART=PART1, IDF=TEST
Defining TCP/IP parameters

This topic describes the parameter settings for Transfer CFT when using TCP/IP.
Specific parameter settings for TCP/IP
Modifying the connection wait timeout period

CFTCONTCP

8 Operations
This timeout period corresponds to a period for Transfer CFT to wait for a communication to be
established. The default timeout period is 120 seconds.
To change this value, set the CFTCONTCP environment variable to the desired value in seconds.
Example
For a period of 20 seconds:
SET CFTCONTCP=20
Parameter settings for the initialization phase

Transfer CFT uses TCP/IP for data transfers with defined remote partners. It also uses this layer for its
own internal exchanges. More particularly for exchanges between the cfttpro.exe and cftn_005.exe
processes.
Certain configurations on the TCP/IP network are incompatible with the d efault options set for
Transfer CFT internal exchanges. These configurations are generally associated with the use of the
DNS and DHCP services. To remedy these difficulties, Transfer CFT’s TCP/IP layer can be
parameterized using the method below:
Define the "TCP LOCALHOSTTYPE" parameter in the cftnet.cfg file.
This parameter can take on the following values:
l LOCALNAME
The HOSTS file or the DNS service is used to obtain the machine’s IP address. The HOSTS file (the
DNS service) must contain the IP address that corresponds to the name of the machine.
Default value:
l LOCALHOST
The standard name "localhost" is used. It is sometimes necessary for the HOSTS file to contain the IP
address of the standard localhost name. In general the value of this IP address is 127.0.0.1.
l IPADDRESS
IP address of the local machine, obtained directly. This is stated in the LOCALHOSTADDR.
Parameter.
If "TCP LOCALHOSTTYPE" is the IPADDRESS, the "TCP LOCALHOSTADDR" p arameter can be
defined. It must be the same as the machine’s IP address. Its default value is 127.0.0.1 (the
standard IP address of the machine).
Note: These parameters are independent of the value of the HOST field in the CFTNET command.
They are used for internal communication between Transfer CFT processes when the CFTNET
command defines the characteristics o f the local resource used for data exchange with remote
partners.
Transfer CFT with RAS example
To use Transfer CFT with RAS, the IP address may be dynamic (DHCP server) without a predefined
host name. You would therefore use the machine’s standard IP address of 127.0.0.1
To do this, define the two following lines in the cftnet.cfg file:

8 Operations
TCP LOCALHOSTTYPE=IPADDRESS
TCP LOCALHOSTADDR=127.0.0.1
Using the TCP/IP via the RAS layer

You can set the Transfer CFT Windows TCP/IP layer parameters to use the Windows RAS service.
This service allows access to a remote TCP/IP via a modem using a PSTN line, Public Switched
Telephone Network.
These services are always proposed when the two systems are installed. The system and network
administrators for the machine on which Transfer CFT is installed are responsible for configuring
these services.
Before attempting to use Transfer CFT via TCP/IP on RAS, the machine using RAS must integrate
with the remote TCP/IP network. This integration is tested once the RAS connection has been made.
The remote hosts specified for Transfer CFT can be reached by the standard utilities of the TCP/IP
layer - PING, TELNET, and so on.
Transfer CFT’s management of the RAS layer is performed using the Microsoft API, the dynamic
library rasapi32.dll. When a Transfer CFT partner is configured to utilize a RAS directory entry, it
manages the RAS connection and disconnection dynamically. The disctd parameter in the CFTPROT
command states the wait time before the RAS disconnects in the absence of another request to
transfer.
Syntax of the CFTTCP HOST parameter:
HOST=PPPxx@host
Where:
l PPPxx: is the name of the section in the cftras.ini file (xx between 00 and 99 inclusive)
l host: corresponds either to the name of the remote host, or the IP address of the
remote partner
The description of the RAS connections used by Transfer CFT is located in the cftras.ini file, in the
Transfer CFT runtime\conf folder. This file has a standard *.INI file structure.
Structure of the cftras.ini file
Each section has the format:
l [PPPxx] : the name of the section (xx between 00 and 99 inclusive)
l linkentry=LINK1 : the entry defined in the Windows RAS directory
l phoneno=1234567890 : the telephone number of the RAS server
l server=server : the NT server on which the user is identified
l username=user : the name of the user connecting to the RAS server
l password=password : the password of the user connecting to the RAS server
Note

8 Operations
l The link entry field, as defined in the RAS directory, is mandatory.
l All the other fields in a section are optional. Their default values are as defined in the RAS
directory entry. If necessary, these optional parameters can replace the parameters defined in
the RAS directory entry.
Security
If a machine possesses several IP addresses, it can receive incoming c alls only on the IP address
given in the HOST field of the CFTNET command.
To receive incoming calls without taking account of the machine’s IP address, you need to set the
value INADDR_ANY in the HOST field of the CFTNET command.
Flow performance
To maximize the transfer flow performance in a CFT environment, you c an modify the TCP Windows
variable in the Windows registry database. Access the cftnet.cfg file and modify the variable: TCP
TCPWINDOWSIZE. There is no minimum or maximum value. You must run Transfer CFT to test the
new variable performance.
Example
Define the following line in the cftnet.cfg file:
TCP TCPWINDOWSIZE=64240
About Windows Application Programming

Interfaces (API)
This section describes the application build features of the Transfer CFT Windows Application
Programming Interfaces, and introduces concepts including:
l Product tool kit
l Before d eveloping your first CFT API application
l Design c onstraints
l Coding c onstraints
l Compilation c onstraints
l Linking c onstraints
l Execution c onstraints
After installation, the runtime\src directory contains the API sources developed in C, Visual
Basic, or DELPHI (capi, delphi, vb subfolders).

8 Operations
Product toolkit
The product comes with a tool kit that enables you to develop an application using the Transfer CFT
programming interfaces, Transfer CFT API applications.
Transfer CFT API applications examples are written in C: Microsoft Visual C++ 4.1, Delphi 2 or Visual
Basic 5.0.
Before developing your first Transfer CFT API

application
Before beginning to write Transfer CFT API applications, you should:
1. Read this topic and the topics in Using APIs,.
2. Familiarize yourself with the sample source files.
l C: ..\CFT\API\C\SRC\APISAMPL.C
l Delphi: ..\CFT\API\DELPHI\SAMPLE\CFTAPIDP.DPR
l Visual Basic: ..\CFT\API\VBASIC\SAMPLE\CFTAPIVB.VBP
3. Copy APISAMPL, CFTAPIDP or CFTAPIVB in the Transfer CFT folder.
4. Start APISAMPL, CFTAPIDP or CFTAPIVB.
5. Rebuild the sample programs from the APISAMPL.C sources and other files (libraries and
definition files) provided.
6. Run the resulting .EXE to test the executables in the sample that you have created.
For issued commands to be interpreted correctly by Transfer CFT, you must:
1. Define a CFTPART with an id of PART1.
2. Define a CFTSEND with an id of TEST and fname called TEST.
3. Set up a file called TEST in the CFT\SEND directory.
4. Start Transfer CFT.
5. Change Windows NT console sessions.
Constraints
Design
The Transfer CFT API functions, which can be called from an application, are not re-entrant. This
means that all Transfer CFT API function calls made by an application must be made in the same
thread.

8 Operations
Coding
A Transfer CFT API application must comply with two requirements:
l When the application starts, but before a Transfer CFT API is called, the Transfer CFT API
initialization function must be called in:
l Visual Basic: Cft_Api_Open (ByVal Version As String) As Integer
l C++ or Delphi: CftInitialize of prototype BOOL CftInitialize (void)
l When the application terminates, it must inform Transfer CFT that it is stopping by calling the
CftUninitialize function with the following prototype: BOOL CftUninitialize ( void )
If they are successful, both functions return TRUE.
Compilation
The apicft.lib dynamic library and APISAMPL.C sample are compiled with the following options:
l Standard mandatory C option:
l Zp1 /* Structures and structure fields aligned on byte boundaries */
l Options specific to WIN32:
l D_X86=1 /* Machine code generation for Intel x 86 processors */
l DWIN32 /* Win 3 2 application */
l D_MT /* Multi-thread application */
l G3 /* Machine c ode generation compatible with 386 processors and compatibles */
Linking
Key Options
Link-editing for a Transfer CFT API application can use all the default o ptions.
Key Libraries
In addition to any application libraries, the key libraries required to build a Transfer CFT API
application are as follows:
l APICFT.LIB
l CFTSCP3.LIB
Execution
To execute an application using Transfer CFT, APIs need the following files:

8 Operations
l Necessary dynamic libraries:
o apicft.dll
o cftscp3.dll
l Additional dynamic libraries for Visual Basic:
o cftvb.dll
l Other files:
o profile
These files must b e installed with the application executables in C or DELPHI on the Windows
workstation, so that the application developed with the Transfer CFT APIs c an run correctly.
A Visual Basic program requires an additional DLL to encapsulate calls to the Transfer CFT APIs
[cftvb.dll].
About Windows Application Programming

Interfaces (API)
This section describes the application build features of the Transfer CFT Windows Application
Programming Interfaces, and introduces concepts including:
l Product tool kit
l Before d eveloping your first CFT API application
l Design c onstraints
l Coding c onstraints
l Compilation c onstraints
l Linking c onstraints
l Execution c onstraints
After installation, the runtime\src directory contains the API sources developed in C, Visual
Basic, or DELPHI (capi, delphi, vb subfolders).
Product toolkit
The product comes with a tool kit that enables you to develop an application using the Transfer CFT
programming interfaces, Transfer CFT API applications.
Transfer CFT API applications examples are written in C: Microsoft Visual C++ 4.1, Delphi 2 or Visual
Basic 5.0.
Before developing your first Transfer CFT API application

Before beginning to write Transfer CFT API applications, you should:

8 Operations
1. Read this topic and the topics in Using APIs,.
2. Familiarize yourself with the sample source files.
l C: ..\CFT\API\C\SRC\APISAMPL.C
l Delphi: ..\CFT\API\DELPHI\SAMPLE\CFTAPIDP.DPR
l Visual Basic: ..\CFT\API\VBASIC\SAMPLE\CFTAPIVB.VBP
3. Copy APISAMPL, CFTAPIDP or CFTAPIVB in the Transfer CFT folder.
4. Start APISAMPL, CFTAPIDP or CFTAPIVB.
5. Rebuild the sample programs from the APISAMPL.C sources and other files (libraries and
definition files) provided.
6. Run the resulting .EXE to test the executables in the sample that you have created.
For issued commands to be interpreted correctly by Transfer CFT, you must:
1. Define a CFTPART with an id of PART1.
2. Define a CFTSEND with an id of TEST and fname called TEST.
3. Set up a file called TEST in the CFT\SEND directory.
4. Start Transfer CFT.
5. Change Windows NT console sessions.
Constraints
Design
The Transfer CFT API functions, which can be called from an application, are not re-entrant. This
means that all Transfer CFT API function calls made by an application must be made in the same
thread.
Coding
A Transfer CFT API application must comply with two requirements:
l When the application starts, but before a Transfer CFT API is called, the Transfer CFT API
initialization function must be called in:
l Visual Basic: Cft_Api_Open (ByVal Version As String) As Integer
l C++ or Delphi: CftInitialize of prototype BOOL CftInitialize (void)
l When the application terminates, it must inform Transfer CFT that it is stopping by calling the
CftUninitialize function with the following prototype: BOOL CftUninitialize ( void )
If they are successful, both functions return TRUE.
Compilation
The apicft.lib dynamic library and APISAMPL.C sample are compiled with the following options:

8 Operations
l Standard mandatory C option:
l Zp1 /* Structures and structure fields aligned on byte boundaries */
l Options specific to WIN32:
l D_X86=1 /* Machine code generation for Intel x 86 processors */
l DWIN32 /* Win 3 2 application */
l D_MT /* Multi-thread application */
l G3 /* Machine c ode generation compatible with 386 processors and compatibles */
Linking
Key Options
Link-editing for a Transfer CFT API application can use all the default o ptions.
Key Libraries
In addition to any application libraries, the key libraries required to build a Transfer CFT API
application are as follows:
l APICFT.LIB
l CFTSCP3.LIB
Execution
To execute an application using Transfer CFT, APIs need the following files:
l Necessary dynamic libraries:
o apicft.dll
o cftscp3.dll
l Additional dynamic libraries for Visual Basic:
o cftvb.dll
l Other files:
o profile
These files must b e installed with the application executables in C or DELPHI on the Windows
workstation, so that the application developed with the Transfer CFT APIs c an run correctly.
A Visual Basic program requires an additional DLL to encapsulate calls to the Transfer CFT APIs
[cftvb.dll].

8 Operations
Building API in Visual Basic

The Transfer CFT API toolkit contains a dynamic library, which enables users to develop a Transfer
CFT API application, that was itself developed in Visual Basic. This library and the sample supplied
have been validated for Visual Basic version 4.0 and higher.
The Transfer CFT APIs enable you to implement the facilities d escribed in About API.
l Cftai: c atalog consultation
l Cftau: transfer commands with syntactical analysis
l Cftac: transfer commands without syntactical analysis
The Transfer CFT API Visual Basic call structures and return c odes are the same as for the equivalent
functions for the Transfer CFT API functions in C. For more information, refer to Using Transfer CFT
services in C.
Visual Basic toolkit

Transfer CFT Windows provides:
l a sample of a Visual Basic program
l a dynamic library c ftvb.dll to allow interfacing between Transfer CFT/Windows XXX with a
Visual Basic application
l a file c ftapivb.bas containing the statements necessary to use the cftvb.dll d ynamic library
The cftvb.dll dynamic library:
l must be visible to all Visual Basic applications using the Transfer CFT APIs
l itself uses the dynamic library apicft.dll (programming interface in C) supplied with Transfer
CFT/Windows, and must therefore be visible to that
l exports the f unctions set out below
The source Visual Basic file cftapivb.bas:
l contains the statements of structure and of functions required to use the Transfer CFT APIs in a
Visual Basic program
l must be incorporated into all projects using the Visual Basic Transfer CFT APIs
Available Visual Basic functions
Initializing and closing a Transfer CFT API application in Visual

Basic
Cft_Api_Open (ByVal Version As String) As Integer
API initialization.

8 Operations
This function must be called before any other Transfer CFT API function.
The parameter is the constant CFT_API_Version as defined in cftapivb.bas.
The return code is 0 if the APIs have correctly initialized.
Cft_Api_Close () As Integer
API close.
This function must be the last Transfer CFT API function called before the application closes.
The return code is 0 if the APIs have correctly closed.
Interrogating the catalogue in Visual Basic

Cft_Cat_Open (ByVal Catalog As String) As Integer
To open the catalog.
The parameter is the name of the catalog file.
The return code is 0 if the catalog is opened. If it does not, see the cftai function (OPEN).
Cft_Clear_Sel (CftSel As CftSelT) As Integer
Initializes a CftSelT structure by filling this structure with binary zeros.
This function must be called before defining the selection criteria to call the Cft_Cat_Select
function.
The parameter is the CftSelT structure that requires cleaning.
The return code is 0.
Cft_Cat_Select (CftSel As CftSelT) As Integer
Selection of records within the open catalog.
The parameter is a correctly filled CftSelT structure (see the Cft_Clear_Cat function).
The return code is 0 if everything is correct. If not, refer to the c ftai C function (SELECT).
Cft_Clear_Cat (CftCat As CftCatT) As Integer
Initializes a CftCatT structure by filling this structure with binary zeros.
This function must be called after every call to Cft_Cat_Next.
The parameter is the CftCat structure that will be used to call Cft_Cat_Next.
The return code is 0.
Cft_Cat_Next (CftCat As CftCatT) As Integer
To read a selected record in the catalogue.
The parameter is an empty CftSelT structure (see the Cft_Clear_Cat function).

8 Operations
The return code is 0 if a record has been raised. If it is not, see the cftai C function (NEXT).
Cft_Cat_Modify (ByVal CatState As String) As Integer
To modify the status of the last record read in the catalogue.
The parameter is a character designating the new status.
The return code is 0 if the status of the record has been modified, o therwise see the cftai C function
(MODIFY).
Cft_Cat_Close () As Integer
To close the catalogue.
The return code is 0 if the catalog has closed. If not, refer to the cftai C function ("CLOSE").
Transfer commands in Visual Basic

Cft_Cmd_Analyse (ByVal Cmd As String, ByVal Parameter As String) As Integer
To send a Cft command with syntactical analysis.
For parameters and return codes (see the cftau function).
Cft_Cmd (ByVal Cmd As String, ByVal Parameter As String) As Integer
To send a Cft command without syntactical analysis.
For parameters and return codes (see the cftac function).
Building an API in C
This section explains how to build Transfer CFT API samples in C. You can also refer to the Transfer
CFT User Guide Using APIs topics for information such as links to sample files.
The API samples and the makefile used to build them are located in your Transfer CFT
<installdir>\runtime\src\capi directory.
Prerequisites
The following steps require that you have Microsoft Visual Studio (VS) and a compiler, such as
Visual C++, installed on your computer.
Procedure
1. From the Windows Start menu, select All programs > Axway software > [Transfer CFT
name] > Transfer CFT > Command Prompt.
This opens a command window, which executes profile.bat.

8 Operations
2. In the same command window, initialize the VS environment by executing the appropriate
vcvarsall.bat based on your system architecture.
l Windows 32 bits: <ProgramFiles>\<VS directory>\VC\vcvarsall.bat
x86
l Windows 64 bits: <ProgramFiles>\<VS directory>\VC\vcvarsall.bat
amd64
l Windows Itanium: <ProgramFiles>\<VS
directory>\VC\vcvarsall.bat ia64
3. To set the CPU environment variable enter the following command based on your Transfer CFT
architecture.
l Windows 32 bits: set CPU=X86
l Windows 64 bits: set CPU=AMD64
l Windows Itanium: set CPU=IA64
4. Go to the directory containing the C source files and makefile:
cd %CFTDIRINSTALL%\runtime\src\capi

5. Enter the command:
nmake /f capi.mak
Results
The nmake command generates the following as either 32-bit or 64-bit executable programs,
depending on the Transfer CFT architecture. The current directory contains the generated object
files and executable programs:
l api2xmp1.exe
l api2xmp2.exe
l apisampl.exe
l tcftsyn.exe
l utisyn.exe
Note The capi.makfile contains a variable called LIB_BUFFEROVERFLOWU whose value may be
set to bufferoverflowU.lib, or left empty depending on the compiler version. You may have
to manually change this variable if it is incompatible with your compiler. Normally this
variable is empty in 64-bit environments.
Remove generated files

To remove all of the generated .obj and .exe files, enter the command:

8 Operations
nmake /f capi.mak clean
Developing exits
This topic describes using exits in Transfer CFT Windows. Every Transfer CFT is supplied with a
toolkit that enables you to develop your own EXITs in C. This topic provides additional information
for developing exits.
The following source examples are supplied in the toolkit:
l File exit
l Directory EXIT
Development environment compilers

You should develop the exits under the Windows operating system, using Microsoft Visual Studio
2003.
Before you begin developing exits
You are strongly advised to do the following before starting the development work itself:
1. Read the general section relating to the developing exits.
2. Read this section.
3. Familiarize yourself with the sample sources in runtime\src\exit.
4. Reconstruct the executable in the sample from the C source and the other files supplied:
libraries, d efinition files, make files.
5. Test the exit of the sample you want to construct.
Functions associated with exits

This section provides information for implementing exits that have already been developed and
supplied with the product, or that are developed specifically by and for a particular user. See Using
exits.
This section describes:
l The different types of exits:
l File exits
l Exit list
l Directory exits
l How to proceed when developing an exit
l How to define Transfer CFT parameters so that it will take account of the different types of exits

8 Operations
The Transfer CFT Exit list guide provides a d escription of a special EXIT file that is already developed
and supplied with Transfer CFT.
Dynamic identification exit upon connection

The aim of the directory type EXIT is to enable the Transfer CFT user to enter dynamically a user
name and/or a password at the connection stage, b efore transmission in request mode.
The prefix for the executable corresponding to this EXIT is CFTEXPWD and it must contain data for
the PROG parameter of the CFTEXIT command in the Transfer CFT parameterization.
The way the EXIT functions depends on the NSPART and NSPASSW parameters in the CFTPART
command:
l If these parameters c ontain any text strings, these strings will be used when the connection is
made.
l If these parameters c ontain the string of "*" (excluding the quotation marks), NSPART and
NSPASSW are entered from a dialog box when the first connection is made to the partner.
l If these parameters c ontain the string of "**" (excluding the quotation marks), NSPART and
NSPASSW are entered from a dialog box every time a connection is made to the partner.
l NSPART and NSPASSW may contain different strings; so if NSPART is entered and NSPASSW =
**, then only the password will be requested each time a connection is made to the partner.
Example
CFTPART ID=PART1
NSPART=*
NSPASSW = **
In this example, Transfer CFT will request the NSPART to be entered when the connection is made
for the first time, and for the password NSPASSW to be entered every time a connection is made.
Exit list
The Transfer CFT EXIT list is an exit that enables remote partners to consult the Transfer CFT catalog
on the central site or on a server. The Exit list guide describes the functions provided by the Exit list
and gives the indications required to implement them.
Transfer CFT Windows supplies the exit list in the form o f an executable cftexl.exe (loaded into
memory when the consultation takes place), accompanied by a sample file containing the selection
criteria, exitlist.txt, which allows the data to be output by the Exit list to be selected from the central
site (or from the server). To use the exit list you also need a definition file CFTNMLOG (see the
section Logical File Names, the paragraph Using a definition file). This is supplied as a sample and
can be used only o n condition that the file name for the selection criteria is exitlist.txt.
Exit example
Exit-list : on server
cftexit id = exitl,
reserv = 8192,

8 Operations
prog = cftexl,
language = c,
mode = replace
cftsend id = texit,
impl = yes,
exit = exitl,
mode = replace
Exit-list remote partner side
cftrecv id = texit,
fname = '&idt.rcv',
fcode = binary,
frecfm = f,
faction = delete,
ftype = b,
mode = replace

TransferCFT InstallationGuide Windows en

Uploaded by

Copyright:

Available Formats

You might also like

TransferCFT InstallationGuide Windows en

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TransferCFT InstallationGuide Windows en

Uploaded by

Copyright:

Available Formats

Transfer CFT 3.3.2 Installation and Operation Guide 3

4 Update, upgrade or migrate 64

Transfer CFT 3.3.2 Installation and Operation Guide 4

Transfer CFT 3.3.2 Installation and Operation Guide 5

6 Create a product deployment package 130

Transfer CFT 3.3.2 Installation and Operation Guide 6

Transfer CFT 3.3.2 Installation and Operation Guide 7

About Transfer CFT

Installation guide outline

Prepare and plan your installation – Describes what you should plan for deploying and

Transfer CFT 3.3.2 Installation and Operation Guide 1

Troubleshoot the installation or registration process – Describes the different types of

Who should read this guide

Transfer CFT documentation set

Transfer CFT 3.3.2 Installation and Operation Guide 2

Accessibility features of the documentation

Screen reader support

Support for high contrast and accessible use of

Transfer CFT 3.3.2 Installation and Operation Guide 3

4 Installation and Operation Guide Transfer CFT 3.3.2

Multi-node license keys

Transfer CFT 3.3.2 Installation and Operation Guide 5

End User License Agreement

Check your authorization

Transfer CFT 3.3.2 Installation and Operation Guide 6

Supported operating systems and browsers

Disk space and RAM requirements

Secure Relay Java installation directory prerequisite

Installer screen resolution

Transfer CFT 3.3.2 Installation and Operation Guide 7

Hardware and software requirements

Apply a service pack or patch, or upgrade using Central

Configure Windows UAC

Transfer CFT 3.3.2 Installation and Operation Guide 8

Set administration rights if UAC is enabled

Tasks that required elevated rights

Windows x86 operating system prerequisites

User rights prerequisites

Transfer CFT 3.3.2 Installation and Operation Guide 9

Service mode prerequisites

Cluster installation requirements

Transfer CFT 3.3.2 Installation and Operation Guide 10

Create a mapped drive

net use Z: \\servername\sharedfolder /persistent:yes

7. Create a Startup script that contains only the command from step 5 (Create the persistent

Remove a mapped drive

Transfer CFT 3.3.2 Installation and Operation Guide 11

net use Z: /delete

Transfer CFT 3.3.2 Installation and Operation Guide 12

Transfer CFT 3.3.2 Installation and Operation Guide 13

Type Location Certificate Expires

Secure <Transfer_CFT>/home/distrib/xsr SecureRelayCA.pem November

Central <Transfer_ passportCA.pem November

Shared file system prerequisites

Transfer CFT 3.3.2 Installation and Operation Guide 14

Transfer CFT data files

Operating Supported Unsupported

AIX GPFS (recommended), NFSv4 NFSv3, CXFS, VeritasSF