Transfer CFT Version 3.3.2 28 July 2020 Installation Guide
OpenVMS
Copyright © 2018 Axway
All rights reserved.
This documentation describes the following Axway AMPLIFY software:
Transfer CFT OpenVMS 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 OpenVMS 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 4 Planning 4 Important information 4 Delivered components 4 End User License Agreement 5 Product license key 5 System requirements 5 Requirements for uploading the installation kit 6 Apply a license key 7 Default ports 9
2 Install 11 Before you start 11 Installation package contents 11 Installation functions 11 Installation modes 11 Installed directories 11 Install Transfer CFT 12 Install Transfer CFT 12 Installing Transfer CFT on a single host 14 Work with files 16 Connector options 18 Platform-specific characters and functions 20 Transfer CFT configuration 21 Transfer CFT internal datafile directory 22 Transfer CFT images 24 Changing the OpenVMS release 25
Transfer CFT OpenVMS 3.3.2 Installation Guide 3 Installing Transfer CFT on multiple hosts 25 Step overview 25 Prerequisites 25 Procedure 26 Deployment packages 29 Install and generate an ExpressPackage 29 Deploy and install the ExpressPackage 35 Silent mode installation 35
3 Post installation 36 Run Transfer CFT for the first time 36 Start/stop Transfer CFT 36 Start Transfer CFT 36 Sending transfer requests 37 Shut down Transfer CFT 38 Use the Copilot server 39 Start the Copilot server 39 Configure the Copilot server 40 Starting multi-node Transfer CFT instances 40 Transfer CFT OpenVMS environment 41 Transfer CFT environment 41 Building the Transfer CFT environment 44 Generating a test Transfer CFT 45 Transfer CFT environment directory 48 Link the Transfer CFT image directory 50 Submit Transfer CFT OpenVMS procedures 52 Transfer CFT to operator messages 54 System specific functions 55 System environment 55 Manage Transfer CFT memory 57 MONIT_MEM utility 59 Transfer CFT procedures 59 Transfer CFT communications 60 Transfer CFT parameter settings 61 Concurrent access to the communication file 63 Multiple Transfer CFT instances on the same system 64 Usethe TCP/IP network 64 Transfer CFT logical names 66 Transfer CFT privileges and identifiers 70 Transfer CFT communications 73 Mailbox communication 76 Build APIs and exits 78 Using the programming interface 78 Using EXIT functions 79
Transfer CFT OpenVMS 3.3.2 Installation Guide 4 Using the programming interface 79 Sentinel Universal Agent 80 Configure Transfer CFT 80 Using the Sentinel Universal Agent 81 Multi-node architecture 82 Working in a multi-node environment 82 About multi-node architecture 83 Multi-node commands 86 Managing multi-node 93 Multi-node unified configuration parameter 95 Transport security 100 Security elements 100 Upload certificates 102 Creating an internal datafile for certificates 103
4 Migrate, upgrade, update 104 Overview 104 Migrate, update, and upgrade 104 Before you start 106 License key requirement 106 Update Transfer CFT 107 Apply a service pack 107 Remove a service pack 108 Apply a patch 108 Remove a patch 109 Manually upgrade Transfer CFT 110 Before you start 110 Display product details 110 Manually upgrade a single installation 110 Manually upgrade a Transfer CFT multi-node installation 112 Migration prerequisites 116 Prerequisites 116 Migrate from Transfer CFT 2.4.1 117 Migrate the configuration 117 Migrate the runtime environment 121 Migrate from Transfer CFT 2.7 123 Migrate the main configuration and UCONF parameters 123 Migrate the PKI certificates 123 Migrate the runtime environment 124 Migrate from Transfer CFT 3.0.1, 3.1.3, or 3.2.4 126 Single node architecture 126 Multi node architecture 128 Single node to multi-node architecture 130
Transfer CFT OpenVMS 3.3.2 Installation Guide 5 5 Uninstall Transfer CFT 131
6 Troubleshooting 132 Troubleshooting 132 Overview 132 Transfer related problems 133 Production related problems 135 System call error messages 136
Transfer CFT OpenVMS 3.3.2 Installation Guide 6 Preface
This documentation provides information to aide you in installing, updating, upgrading, or migrating Transfer CFT.
About Transfer CFT OpenVMS 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 OpenVMS. 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.
Transfer CFT OpenVMS 3.3.2 Installation Guide 1 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 OpenVMS 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 [email protected] or, for your local support telephone number, visit support.axway.com and click Contact Axway Support.
Transfer CFT OpenVMS 3.3.2 Installation Guide 2 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.
Transfer CFT OpenVMS 3.3.2 Installation Guide 3 Prerequisites 1
Planning This document describes how to prepare for and install Transfer CFT in an OpenVMS environment.
Important information Each supplied product must be installed or updated using the VMSINSTAL installation procedure. If you are changing systems, use the installation procedure to install Transfer CFT VMS on your new environment. Never use a backup of your previous disk, as the procedure updates some of the files in the user account.
Delivered components The Transfer CFT is distributed as a zip file from Axway Website. Use the VMSINSTAL utility to install the product.
Preparation Use the following list to prepare for installation.
l Check software licenses for installation
l Verify that the zip file is available.
l If installing from an alternate software source, verify that the software zip file is accessible.
l Verify the license keys for each of the hostnames are received.
Database
l Verify that the Database server is available.
l Verify the number of connections, and how many are dedicated Axway connections?
User accounts and permissions
l Verify that user accounts have been created and username/password are known.
l Are the appropriate permissions in place?
Transfer CFT OpenVMS 3.3.2 Installation Guide 4 1 Prerequisites
Server access and connectivity
l Check that you can log in as system administrator.
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.
Product license key
Product license key. Enter the product license key. Alternatively, you can set the Transfer CFT key in the CFT_SCEN:CFT.KEY. * Enter the license key: --> Type M to modify, ENTER to continue: Generate Encryption Key Please specify a seed password to generate the encryption key: Warning: The password must contains at least 8 characters, contain upper and lower case characters as well as numeric and special characters (*#$!?+-@ * Password: * Confirm password: Choose a location to store the generated key and salt files: * Key file ...... [CRYPKEY.KEY]: * Salt file ...... [CRYPSALT.KEY]: --> Type M to modify, ENTER to continue:
System requirements The installation process lasts approximately 10 to 15 minutes, depending on the system. It is performed from an account that has special privileges.
Note VAX systems are currently not supported by Transfer CFT 3.3.2 and higher.
Installation requirements include:
l IA64: approximately 665,000 blocks of free disk space
l At least 3,400 free global pages and two global sections to use Transfer CFT
l At least 400 free global pages and two global sections to use Copilot
Transfer CFT OpenVMS 3.3.2 Installation Guide 5 1 Prerequisites
These values are sufficient if all Transfer CFT users belong to the same group, in UIC terms. Otherwise, multiply these values by the number of different user groups to calculate the total system requirement.
To use different networks with Transfer CFT, you must install these products.
The privileges, identifiers and quotas required to execute Transfer CFT are automatically assigned by the installation procedure to the account associated with the product. Some of these privileges and quotas must be assigned to the various Transfer CFT users.
Requirements for uploading the installation kit
l An installed FTP server on the OpenVMS system
l An FTP user with rights to upload files
l A connection between the local machine and the OpenVMS system
l Alternatively, use the binary mode to transfer the zip file
Transfer CFT OpenVMS 3.3.2 Installation Guide 6 1 Prerequisites
Defaults and system values The following table lists the ports and their uses with Transfer CFT OpenVMS. Additionally, you can print and record the values for your own installations.
Used for... Port Number Firewall Your (default) installation
Available 1761 to 1768 N/A
PeSIT 1761
Copilot Server 1766
Synchronous API 1765
Single Authentication 1762 Bidirectional
Mutual Authentication 1763
Proxy port
Database
HTTPS
Additional information
Transfer CFT IP address
CA and password for root CA
License information
Apply a license key 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.
l A hardware upgrade can change the CPU ID (CPU serial number); if so, you must reapply the license.
Transfer CFT OpenVMS 3.3.2 Installation Guide 7 1 Prerequisites
Obtain a license key
1. Install Transfer CFT. You can install Transfer CFT without a license key, and enter the key later. 2. After completing the installation, or for an existing installation, use the command cftutil about to retrieve your system information. 3. Contact the Axway Fulfillment team at the appropriate email address to obtain a key.
l For a US key, contact: [email protected]
l For an EMEA or APAC key, contact: [email protected] 4. Apply the license key(s) that you received from the Axway Fulfillment team as follows:
l Enter the key in the default file: CFT_SCEN:CFT.KEY.
Apply a license key Apply the license key(s) that you received from the Axway Fulfillment team as follows:
l Enter the key in the default file: CFT_SCEN:CFT.KEY.
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 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.
Transfer CFT OpenVMS 3.3.2 Installation Guide 8 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
*not supported
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
Transfer CFT OpenVMS 3.3.2 Installation Guide 9 1 Prerequisites
authentication)
l Central Governance: Used to connect to Central Governance
Transfer CFT OpenVMS 3.3.2 Installation Guide 10 Install 2
Before you start AMPLIFY Managed File Transfer is part of the AMPLIFY family of managed file transfer (MFT) products. Transfer CFT is a transfer exchange system that enables reliable and secure internal file transfers between applications.
If you are installing Transfer CFT OpenVMS as part of an Axway Managed File Transfer solution, you may want to check the installation order and prerequisites. For more information, please refer to the Central Governance documentation.
Before you start the installation, you should:
l Download the installation package from Axway Sphere.
l Unzip the package.
Installation package contents The installation package is a zip archive. You should unzip it on the OpenVMS machine. Once you unzip it, it contains the product and the installation procedure (installer).
Installation functions The installer is used to install, configure, update and uninstall Transfer CFT, which is part of the Axway 5 Suite. You can run the following installation modes:
l Install
l Configure
l Update
l Uninstall
Installation modes Use the standard SYS$UPDATE:VMSINSTAL procedure to install the product.
Installed directories Once you install a product, the following sub-directories are installed.
Transfer CFT OpenVMS 3.3.2 Installation Guide 11 2 Install
l [.CFT.HOME] contents files of the product.
l [.CFT.RUNTIME] contents mainly configuration files and executables.
Install Transfer CFT
Install Transfer CFT The Transfer CFT product comprises the Transfer CFT and the utilities supporting communications between Transfer CFT and users.
The installation procedure creates the environment in which Transfer CFT is to be executed. The system manager is responsible for assigning users the appropriate quotas and privileges to access the tools used to dialog with Transfer CFT.
There are two types of installation:
l Initial product installation: This procedure generates a full environment, comprising a standard directory structure. When the installation terminates correctly, a procedure is used to generate configuration files that enable you to perform a test loop-back transfer.
l Upgrade: This installation procedure renames the previous Transfer CFT subdirectories and generates a new standard installation directory structure.
See the Product license key on page 5 section for information on the license key and the end user license.
Pre-installation To prepare for the installation procedure:
1. Log into a privileged account and access the SYS$UPDATE directory. Enter the user name and password.
Username: SYSTEM
Password:
2. Access the directory where you uploaded the zipped installation kit files. This zip file, TransferCFT_3.3.2_vms-ia64_
l cft033.a
l cft033.b
l cft033.c
l cft033.d 3. Unzip the file: unzip TransferCFT_3.3.2_vms-ia64.zip
Transfer CFT OpenVMS 3.3.2 Installation Guide 12 2 Install
Start the installation
1. Enter the command: @sys$update:vmsinstal cft033
The OpenVMS Software Product Installation Procedure screen is displayed.
2. Follow the screen instructions as shown in the following example installation.
*Do you want to continue anyway [NO]? y * Are you satisfied with the backup of your system disk [YES]? Where will the distribution volumes be mounted: AXP2$DKB400: [CFTPATH.ia64] * Enter installation options you wish to use (none): The following products will be processed: CFT V3.3 Beginning installation of CFT V3.3 at 14:34
3. Define the installation options.
First Transfer CFT 332 installation 1 * Option selected [1]: Select 1 to install Transfer CFT 332. NOTE: Options 2 and 3 are not available in the RA version of Transfer CFT 3.3.2 VMS.
4. Define the groups that can connect to Transfer CFT.
WARNING The following restrictions apply when using Transfer CFT in a multi-node architecture. The Transfer CFT user must be available on all machines where you are installing Transfer CFT, and have the same group number and user ID.
For each user group that connects to Transfer CFT via CFTUTIL, COPILOT or Transfer CFT APIs, Transfer CFT uses 4 global sections for an approximate total of 10500 global pages, with each global section being shared by all users that are in the same group. * Number of groups using Transfer CFT [1]:
5. Define the Transfer CFT user account. The user name entered during installation is displayed, otherwise the default value CFTVMS is used.
* Name of Transfer CFT account [CFTVMS]: Do you want to use CFTVMS as the profile? * Do you want to update the profile [Yes]:
Transfer CFT OpenVMS 3.3.2 Installation Guide 13 2 Install
6. Select the transfer options.
* Maximum of simultaneous transfers (all networks) [32]: * Maximum of file sub-processes [8]: * Maximum of transfers per file sub-process [8]: You can select the DEC Network: * Will CFT use the DECnet network [Yes]: * Name of the batch queue used by CFT [SYS$BATCH]: This feature requires the CMKRNL privilege. * Will procedures be executed for the transfer owner user [No]:
Tip See also Installing Transfer CFT on a single host, or Installing Transfer CFT on multiple hosts.
Installing Transfer CFT on a single host This section describes how to install Transfer CFT 3.3.2 on a single host. As described in this section, you may opt to run multiple instances of Transfer CFT on a single host to optimize the hardware architecture, for example.
To begin the procedure:
1. Select the single host option to perform a classic Transfer CFT installation:
Installation type: Single host or multiple hosts. * Single host(1) - Multiple hosts (2)...... [1]:
2. Specify the root and shared directories for components to install. The default directory is the login directory for the Transfer CFT account.
Single Host. Specify the root and shared directories for components to install. * Installation Directory [AXP2$DKB400:[MYDIRPATH]]: AXP2$DKB400:[ MYDIRPATH]
3. Set the multi-node option. If you want to install Transfer CFT on a single host but run multiple instances of Transfer CFT, set the multi-node option to (Y)es. If you activate multi-node, you are prompted to enter the number of Transfer CFT nodes, from 2 to 4 nodes.
* Enable the multi-node architecture Y/N [N]: --> Type M to modify, ENTER to continue:
Transfer CFT OpenVMS 3.3.2 Installation Guide 14 2 Install
4. Enter the product license key. Alternatively, you can set the Transfer CFT key in the CFT_ SCEN:CFT.KEY file after installation.
Product license key. * Enter the license key. Alternatively, you can set the Transfer CFT key in CFT_SCEN:CFT.KEY:
5. Enter the local Transfer CFT instance details.
l Group name: Use this field to assign your Transfer CFT to a Transfer CFT group.
l Local name: This value is your CFTNAME, as defined by LOCALPART in CFTPARM by default. See also the UCONF values.
Local Transfer CFT instance details. * Group Name ...... [Production.VMS]: * Local Name ...... [I64OV1_MYCFTNAME]: * Hostname [I64OV1.LAB1.LAB.LOCAL.COMPANY.INT]: --> Type M to modify, ENTER to continue:
6. For the sample default TCP/IP cft-tcp.conf file, enter the ports as needed.
* The synchronous communication [1765]: * The PeSITany protocol ...... [1761]: * The PeSIT protocol using SSL .. [1762]: --> Type M to modify, ENTER to continue:
7. Define the default database size for the catalog and communication files.
* Catalog file - nb of records.. [10000]: * Comm. file - nb of records .... [1000]: --> Type M to modify, ENTER to continue:
8. Enter the listening port for the Transfer CFT User Interface (UI).
* Listening port ...... [1766]: --> Type M to modify, ENTER to continue:
9. Configure the Transfer CFT connectors according to your system setup.
* Sentinel Y/N? ...... [N]: * Composer Enabler Y/N? ...... [N]: * P K I with PassPort Y/N? ...... [N]: * Access Management - PassPort Y/N? [N]:
Transfer CFT OpenVMS 3.3.2 Installation Guide 15 2 Install
--> Type M to modify, ENTER to continue:
After completing the installation process, go to Starting Transfer CFT.
Work with files
Transferred files physical properties Transferred files can be designated by physical or logical names. As the files are accessed by Transfer CFT sub-processes, the logical names used must be defined in a table of logical names at least at JOB level.
The physical file name must include the name and name extension. If there is no extension, add the '.' character to the end of the file name. Otherwise, the transfer fails with an ERRLREC error.
Information on physical file properties is exchanged between partners during every transfer.
Sender
These values are given explicitly in the CFTSEND command or by sending a request to an RMS service.
Receiver
These values are given explicitly in the CFTRECV command or received at protocol level.
The following table describes the physical properties for transferred files.
Parameter Definition
FSPACE Disk space occupied by the file in KB.
FLRECL Maximum size of a record in the file.
FBLKSIZE The first multiple of 512 greater than the length of the record in the file.
FRECFM Record format (Fixed / Variable / Undefined).
FORG File organization (Seq / Direct / Indexed).
FTYPE File type. A character that specifies the physical type of file (see table below).
FCODE Code type (ASCII/EBCDIC/BINARY). Default value assigned according to the file FTYPE (see table below).
FKEYLEN For an indexed file: key length.
FKEYPOS For an indexed file: key offset in the record.
Transfer CFT OpenVMS 3.3.2 Installation Guide 16 2 Install
The following table describes the FTYPE, FRECFM and FCODE assigned by Transfer CFT according to the file type.
FAB Record Format FRECFM FTYPE FCODE Field Value (FAB$B_RFM)
FAB$C_FIX 'F' ' ' ASCII
FAB$C_UDF 'U' ' ' ASCII
FAB$C_VAR 'V' 'P' ASCII
FAB$C_VFC 'V' 'C' ASCII
FAB$C_STM 'V' 'F' ASCII
FAB$C_STMLF 'V' 'L' ASCII
FAB$C_STMCR 'V' 'R' ASCII
The following table describes the file type according to the FRECFM and FTYPE parameters.
FRECFM FTYPE FAB Record Format Field Value (FAB$B_RFM)
'F' FAB$C_FIX
'U' FAB$C_UDF
'V' 'C' FAB$C_VFC
'V' 'F' FAB$C_STM
'V' 'L' FAB$C_STMLF
'V' 'R' FAB$C_STMCR
'V' 'P' FAB$C_VAR
Received file versions During receive operations, Transfer CFT can generate successive file versions according to the file name syntax associated with the CFTRECV command.
l
l
Transfer CFT OpenVMS 3.3.2 Installation Guide 17 2 Install
transfer is refused. If it exists in the same version, the transfer might be refused, depending on the CFTRECV command FACTION and FDISP parameters. The file envelope is reused or deleted and then recreated.
l
Note If you use the
Connector options
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. Sentinel Connector Enter 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
Transfer CFT OpenVMS 3.3.2 Installation Guide 18 2 Install
Screen Description
Transfer CFT: This screen is only displayed if you enabled PassPort PKI PassPort PKI connectivity. Enter values for the following parameters: connector l PKI Server Host Address: Sets the Sentinel server hostname on which the connector will connect to
l PKI Server Port: Sets the Sentinel Server port on which the connector will connect to
l Use SSL
l PKI server public certificate
l Copy certificate
l PKI server login
l PKI Server Password
l 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 Sentinel server hostname on connector which the connector will connect to
l AM Server Port: Sets the Sentinel Server port on which the connector will connect to
l Use SSL
l AM Server public certificate
l Component instance
l Domain
l Component Login
l Component Password
l Confirm Password
Implementing the heartbeat functionality When the Transfer CFT heartbeat function is activated, it sends the attributes to the Sentinel server via TRKUTIL. The Transfer CFT heartbeat combined with a Status Dashboard allows you to monitor Transfer CFT, providing information on the Transfer CFT status from indicators such as the Transfer CFT state, Transfer CFT catalog file space, process activity, version, memory and CPU usage, and so on.
For more information on Dashboards and tracked objects, refer to the Sentinel User's Guide.
Note To enhance performance, you can install the Event Router on the same machine as the Transfer CFT.
Transfer CFT OpenVMS 3.3.2 Installation Guide 19 2 Install
Check that the unified configuration values are set as follows for heartbeat functionality:
l sentinel.heartbeat.enable = YES
l sentinel.heartbeat.periodicity = 300: This recommended value has a direct correlation with the value defined in the Monitoring requests.
l sentinel.heartbeat.script = D$CFT_INST:[extras.sentinel]MFTheartbeat.com: The script name and path according to your system environment.
l sentinel.trkipaddr = sentinel.server.address
l sentinel.trkipport = Sentinel.qlt/auto.port value (default = 1305)
l sentinel.xfb.enable = YES
Platform-specific characters and functions Certain characters have a unique meaning in commands as well as in the Transfer CFT configuration.
On z/OS and IBM i platforms you should check the page code used by your local system. For example, x'5B' is the pound character (£) if you are using the United Kingdom EBCDIC page code 285, but is the dollar character ($) in the French EBCDIC page code 297. For more information, please refer to the IBM site: ccsid_registered.html.
Description Windows Unix z/OS IBM i OpenVMS
char_file Logical name $ _ x'5B' x'4E' No specific prefix 285 = 285 = character; £ + logical 297 = 297 = names are $ + processed transparently by RMS
char_ Wildcard ? ? x' 6F x'6F' %x mask character 285 = 285 = ? ? 297 = 297 = ? ?
char_ Separator % \01 x' 6C' x '5E' No volume unit character 285 = 285 = concept (volume) % ; 297 = 297 = % ;
Transfer CFT OpenVMS 3.3.2 Installation Guide 20 2 Install
Description Windows Unix z/OS IBM i OpenVMS
char_ Symbolic & & x'50' x'6F' & symb variable prefix 285 = 285 = & ? 297 = 297 = & ?
file_ Character # @ x'7B’ x'B1' Either # or symb introducing a 285 = 285 = @ file # [ name passed 297 = 297 = to CFTUTIL as £ # a parameter
char_ Character + + + + + directory introduced in Limited Limited the path to to name of the USS HFS FNAME files files parameter (CFTRECV) from which a tree structure can be created
cont Continuation - - - - - character in CFTUTIL commands
Note OpenVMS is not available for Transfer CFT 3.3.2 using Central Governance.
Transfer CFT configuration This section describes the specific features of the Transfer CFT OpenVMS configuration, and the reserved characters and configuration commands.
Some configuration commands include specific features that enable Transfer CFT to be more effectively integrated into a OpenVMS environment. These features affect certain reserved characters, the network configurations, and the definition of the files to be transferred.
CFTUTIL, Copilot, and API default values The following table lists the default values that are used for Transfer CFT files.
Transfer CFT OpenVMS 3.3.2 Installation Guide 21 2 Install
Object Specific value
Parameter file CFTPARM
Partner file CFTPART
Catalog file CFTCATA
Log file CFTLOG
Communication file CFTCOM
Statistics file CFTACCNT
Alternate statistics file CFTACCNTA
Default media File
Reserved characters for Transfer CFT configuration Some characters have a unique meaning in commands and Transfer CFT configuration.
Notation Object Specific Value
char_file Logical name prefix No specific character, as the logical names are processed transparently by RMS
char_mask Wildcard character %
char_unit Separator character (volume) No volume concept on OpenVMS
char_symb Symbolic variable prefix &
file_symb Character introducing a file name Either # or @ passed to CFTUTIL as a parameter
Transfer CFT internal datafile directory Logical name CFT_DAT points to D$CFT:[CFT.RUNTIME.DATA] directory, which contains the internal datafile files used by Transfer CFT.
Transfer CFT OpenVMS 3.3.2 Installation Guide 22 2 Install
File Contents
CFTPARM.INX CFT PARAMETER file. This file is not supplied. It is created by CFTUTIL in the CFTDAT procedure.
CFTPART.INX CFT PARTNER file. This file is not supplied. It is created by CFTUTIL in the CFTDAT procedure.
CFTCATA.REL CFT CATALOG file. This file is not supplied. It is created by CFTUTIL in the CFTDAT procedure.
CFTCOM.REL CFT COMMUNICATION file. This file is not supplied. It is created by CFTUTIL in the CFTDAT procedure.
CFTKEY.PARM This file contains the CFT license key
SEND.DIR Directory with default file (sample) to send when it is not specified.
RECV.DIR Default directory to receive the transferred files.
X.509 certificate directory This directory contains the X.509 certificates.
D$CFT:[CFT.CFTPKI] => CFT_PKI Directory
Transfer CFT log file directory Logical name CFT_LOG points to D$CFT:[CFT.RUNTIME.LOG] directory, which stores Transfer CFT log files.
File Contents
CFTLOG.LOG CFT LOG file. This file is not supplied. It is created by CFTUTIL in the CFTDAT procedure.
CFTLOG.LOGA CFT LOG file. This file is not supplied. It is created by CFTUTIL in the CFTDAT procedure.
Transfer CFT OpenVMS 3.3.2 Installation Guide 23 2 Install
File Contents
CFTACCNT.LOG CFT ACCOUNT file. This file is not supplied. It is created by CFTUTIL in the CFTDAT procedure.
CFTACCNT.LOGA CFT ACCOUNT file. This file is not supplied. It is created by CFTUTIL in the CFTDAT procedure.
CFTMAIN.LOG Log of CFTMAIN task.
COPSMNG.LOG Log of Copilot task.
TRKTRACE.LOG Log of Sentinel task.
Files to send directory The D$CFT:[CFT.CFTSEND] => CFT_SEND directory used to store the files to be sent in the sample configurations.
D$CFT:[CFT.CFTSEND] => CFT_SEND directory
File Contents
TEST.SND Variable sequential file.
FIXED.SND Fixed sequential file.
Rebuild Transfer CFT directory The D$CFT:[CFT.LIB] => XMK_BDIR:[LIB] directory contains the libraries and objects required to rebuild Transfer CFT.
Transfer CFT images This section describes the operations that you should perform when changing the OpenVMS release.
All of the files required to build the Transfer CFT images are supplied in the XMKT_BDIR :[OPT] and XMKT_BDIR :[LIB] directories.
The LINK.COM procedure in the XMKT_BDIR :[OPT] directory is used to link all the images.
In some cases, you must redo the Transfer CFT images link.
Transfer CFT OpenVMS 3.3.2 Installation Guide 24 2 Install
Changing the OpenVMS release Normally, you do not need to re-link Transfer CFT because OpenVMS upward compatibility is guaranteed by the vendor. However, if this is not the case, you must re-link all of the images in the CFT_EXE: directory.
1. To perform the link operation, enter the command: $ @XMKT_BDIR:[OPT]cft_link
$ @XMKT_BDIR:[OPT]cop_link
2. Purge the previous images in the CFT_EXE: directory.
Installing Transfer CFT on multiple hosts Installing a multi-host Transfer CFT architecture requires additional prerequisites and installation steps beyond those described in the single host installation procedure.
Step overview
1. Install the first machine using the First host installation option.
l For the first host installation, you should enter all hosts for the installation architecture.
l You must at this point enter the shared directory that will be used by all of the hosts and machines in the setup.
l This first installation saves all of the initial information for the additional machine installations. 2. Install all additional machines using the Additional host installation option, for example the second and third machine.
l Do not select First host for an additional host installation.
l You are prompted to enter the shared directory location, as defined in the previous step.
Prerequisites To install Transfer CFT OpenVMS in a cluster you require:
l Multiple machines on which each of these the Transfer CFT binaries can be installed in the installation directory path.
l A shared directory that is available for all of the machines where the Transfer CFT runtime will be installed and shared.
Transfer CFT OpenVMS 3.3.2 Installation Guide 25 2 Install
Procedure To begin the procedure:
1. Select Option 2 to install Transfer CFT on multiple hosts.
Installation type: Single host or Multiple hosts. * Single host(1) – Multiple Hosts(2)...... [1]: 2
2. Select the option that corresponds with your installation. You can define either the first host in this screen, or additional host installations according to the planned architecture.
First host: Installs Transfer CFT on the first Host...... (1) Additional host: Installs Transfer CFT on an additional Host (2) * Selected option [1]:
3. Specify the root and shared directories for components to install. The default directory is the login directory for the Transfer CFT account.
l Installation directory: Path of the first host
l Shared Directory: Shared Disk path, the shared disk is shared by all installed hosts
l Runtime Directory: The Transfer CFT runtime is installed in the shared folder
First host. * Installation Directory [AXP2$DKB400:[CFTPATH]]: * Shared Directory [AXP2$DKB400:[ CFTPATH.SHARED]]: * Runtime Directory AXP2$DKB400:[ CFTPATH.SHARED.cft.runtime] --> Type M to modify, ENTER to continue:
4. Enter the local Transfer CFT instance details.
l Group name: Use this field to assign your Transfer CFT to a Transfer CFT group. This value is used for Transfer CFT Navigator and Composer, if your setup includes these additional components.
l Local name: This value is your CFTNAME, as defined by LOCALPART in CFTPARM by default. See also the UCONF values.
* Group Name ...... [Production.VMS]: * Local Name ...... [I64OV1_MYCFTNAME]: * Hostname [I64OV1.LAB1.LAB.LOCAL.COMPANY.INT]: --> Type M to modify, ENTER to continue:
Transfer CFT OpenVMS 3.3.2 Installation Guide 26 2 Install
5. Enable the multi-nodes architecture. Then enter the number of nodes in the setup and the hostnames.
* Number of nodes ..... [2]: (1 to 4) Specify hosts that take part of the multi-node architecture. * Number of hosts ..... [2]: (1 to 4) * Hostname 0 ______HOSTNANE_N°1 * Host address 0 ______HOSTNAME_N°1.LONG.ADDRESS.COM * Hostname 1 ...... : HOSTNANE_N°2 * Host address 1 ...... : HOSTNAME_N°2.LONG.ADDRESS.COM --> Type M to modify, ENTER to continue:
6. Enter the product license keys, where each node requires a key per host. Alternatively, you can set the Transfer CFT key in the CFT_SCEN:CFT.KEY file after installation.
Product license key. Enter the product license keys, where each node requires a key per host. Alternatively, you can set the Transfer CFT key in CFT_SCEN:CFT.KEY: * License Key for host1:
7. For the sample default TCP/IP cft-tcp.conf file, enter the ports as needed.
* The synchronous communication [1765]: * The PeSITany protocol ...... [1761]: * The PeSIT protocol using SSL .. [1762]: --> Type M to modify, ENTER to continue:
8. Define the default internal datafile size for the catalog and communication files.
* Catalog file - nb of records.. [10000]: * Comm. file - nb of records .... [1000]: --> Type M to modify, ENTER to continue:
Transfer CFT OpenVMS 3.3.2 Installation Guide 27 2 Install
9. Enter the listening port for the Transfer CFT User Interface (UI).
* Listening port ...... [1766]: --> Type M to modify, ENTER to continue:
10. Enter the listening port for the Transfer CFT User Interface (UI).
* Listening port ...... [1766]: --> Type M to modify, ENTER to continue:
11. Configure the Transfer CFT connectors according to your system setup.
* Transfer CFT Navigator Y/N? ...... [N]: * Sentinel Y/N? ...... [N]: * Composer Enabler Y/N? ...... [N]: * P K I with PassPort Y/N? ...... [N]: * Access Management - PassPort Y/N? [N]: --> Type M to modify, ENTER to continue:
After completing the installation process, go to Starting Transfer CFT.
Transfer CFT OpenVMS 3.3.2 Installation Guide 28 2 Install
Deployment packages This section describes how to create a Transfer CFT OpenVMS deployment package, referred to as an ExpressPackage, for an OpenVMS environment. It details how to create a reusable and distributable Transfer CFT package to ease the task of installing and configuring Transfer CFTs on multiple servers having the same architecture.
The procedure consists of:
l Installing and generating an ExpressPackage that is based on the configured template
l Deploying and installing the generated Express Package
Install and generate an ExpressPackage To create your ExpressPackage:
1. Begin by installing a Transfer CFT instance that meets your business needs. This configured Transfer CFT serves as the template for the ExpressPackage you are about to create. 2. Create an ExpressPackage from the template Transfer CFT.
a. Generate the product_name.ANS file, for example sys$update:CFT033.ANS.This file consists of a collection of questions and responses that display as one question per line.
l Use the VMSINSTALL command procedure's OPTION A (the auto-answer option) to start the procedure:
$@sys$update:vmsinstal cft033 DKB0:[TRANSFER_CFT_ V3_3_2_VMS-ALPHA.INSTALL] OPTIONS A
l If the file exists in the directory, the VMSINSTALL procedure performs a new Transfer CFT installation (silent mode). If the file does not exist, it is created.
l The product_name.ANS file is then created in the sys$update directory.
b. Reply to the product_name.ANS file questions. For example:
OpenVMS AXP Software Product Installation Procedure V7.3-2
It is 26-MAR-2017 at 11:06. Enter a question mark (?) at any time for help. %VMSINSTAL-W-ACTIVE, The following processes are still active: TCPIP$FTP_1 * Do you want to continue anyway [NO]? y * Are you satisfied with the backup of your system disk [YES]? The following products will be processed: 1.
Transfer CFT OpenVMS 3.3.2 Installation Guide 29 2 Install
CFT V3.3 Beginning installation of CFT V3.3 at 11:06 %VMSINSTAL-I-RECORDANS, An auto-answer file will be recorded. %VMSINSTAL-I-RESTORE, Restoring product save set A ... ------Warning: ------Logical names have not been detected CFTDIRINSTALL and CFTDIRRUNTIME To update an existing account CFT, please load the CFTLOGIN.COM ############################################## ### First installation of Transfer CFT ... ### ############################################## For each user group that connects to Transfer CFT via CFTUTIL, COPILOT, or Transfer CFT APIs, Transfer CFT uses 4 global sections for an approximate total of 10500 global pages, with each global section being shared by all users that are in the same group. * Number of groups using CFT [1]: %CFT-I-IDENTIFIER, Test of existence COPILOT identifier in SYSUAF. -CFT-I-IDENTIFIER, Ignore any error messages ... %UAF-E-RDBADDERRU, unable to add COPILOT value [000000,000000] to rights database -SYSTEM-F-DUPLNAM, duplicate name %CFT-I-IDENTIFIER, End of test. * Name of Transfer CFT account [CFTVMS]: CFTVM1 Do you want to use CFTVM1 the profile? * Do you want to update the profile [Yes]: Owner Username UIC Account Privs Pri Directory CFTVM1 [402,402] All 4 DKB0:[CFTVM1] %CFT-W-USEREXISTS, 9 -CFT-W-USEREXISTS, The CFTVM1 account already exists. -CFT-W-USEREXISTS, The procedure will update it. * Do you wish to continue [Yes]: CFT is a multi-task file transfer monitor. It supports the TCP/IP networks. To optimize file accesses, CFT can create up to eight sub-processes to control up to eight transfers each and a total of up to 64 transfers at any one time.
Transfer CFT OpenVMS 3.3.2 Installation Guide 30 2 Install
Depending on your requirements, the account running the monitor uses specific privileges and the associated system resources. * Maximum of simultaneous transfers (all networks) [32]: * Maximum of file sub-processes [8]: * Maximum of transfers per file sub-process [8]: * Number of transfers in SNA mode [0]: CFT can submit command procedures on detection of specific events (log file full, end of transfer, transfer error and so on). These procedures are submitted in batch mode in the queue of your choice. * Name of the batch queue used by CFT [SYS$BATCH]: End of transfer procedures can be executed for the CFT monitor or the owner of the transfer. This feature requires the CMKRNL privilege. * Will procedures be executed * for the transfer owner user [No]: y %CFT-I-IDENTIFIER, Test for the existence of the PSI$DECLNAME identifier -CFT-I-IDENTIFIER, in SYSUAF. -CFT-I-IDENTIFIER, Ignore any error messages ... %CFT-I-IDENTIFIER, End of test. %CFT-I-IDENTIFIER, Test for the existence of the PSI$X25_USER identifier -CFT-I-IDENTIFIER, in SYSUAF. -CFT-I-IDENTIFIER, Ignore any error messages ... %CFT-I-IDENTIFIER, End of test. %CFT-I-IDENTIFIER, Test for the existence of the NET$EXAMINE identifier -CFT-I-IDENTIFIER, in SYSUAF. -CFT-I-IDENTIFIER, Ignore any error messages ... %CFT-I-IDENTIFIER, End of test. %CFT-I-IDENTIFIER, Test for the existence of the X25_OUTGOING_ ALL identifier -CFT-I-IDENTIFIER, in SYSUAF. -CFT-I-IDENTIFIER, Ignore any error messages ... %UAF-E-SHOWERR, unable to complete SHOW command -SYSTEM-F-NOSUCHID, unknown rights identifier %CFT-I-IDENTIFIER, End of test. %SEARCH-I-NOMATCHES, no strings matched Installation type: Single host or Multiple hosts.
Transfer CFT OpenVMS 3.3.2 Installation Guide 31 2 Install
* Single host(1) - Multiple Hosts(2)...... [1]: Single Host. Specify the directory where you want to install the components. (Default directory: login directory for the CFT account). * Installation Directory [DKB0:[CFTVM1]]: DKB0:[CFTVM1.TEST] The installation directory specified is different from the login directory for the CFTVM1 account. * Enable the multi-node architecture Y/N [N]: y * Number of nodes ...... [2]: 3 --> Type M to modify, ENTER to continue: Product license key. Enter the product license keys, where each node requires a key per host. Alternatively, you can set the Transfer CFT keys in th e CFT_SCEN:CFT.KEY. * License Key for node0 in host0: * License Key for node1 in host0: * License Key for node2 in host0: --> Type M to modify, ENTER to continue:
(ALL - no longer multi node - start a new window) Enter the local Transfer CFT instance details. * Group Name ...... [Production.VMS]: * Local Name ...... [AXP3_CFTVM1]: * Hostname [AXP3.LAB1.LAB.LOCAL.COMPANY.INT]: --> Type M to modify, ENTER to continue:
Sample - Default TCP/IP port (cft-tcp.conf file) * The synchronous communication [1765]: * The PeSITany protocol ...... [1761]: * The PeSIT protocol using SSL .. [1762]: --> Type M to modify, ENTER to continue: Default database size * Catalog file - nb of records.. [10000]: 1000 * Comm. file - nb of records .... [1000]: --> Type M to modify, ENTER to continue: Transfer CFT User Interface (UI) * Listening port ...... [1766]: --> Type M to modify, ENTER to continue:
Transfer CFT OpenVMS 3.3.2 Installation Guide 32 2 Install
Configure the following connectors * Transfer CFT Navigator Y/N? ...... [N]: * Sentinel Y/N? ...... [N]: * Composer Enabler Y/N? ...... [N]: * P K I with PassPort Y/N? ...... [N]: * Access Management - PassPort Y/N? [N]: --> Type M to modify, ENTER to continue: ************************************************* SUMMARY OF SETTINGS ************************************************* Installation type: Single host Hostname = AXP3.LAB1.LAB.LOCAL.COMPANY.INT Group Name = Production.VMS Local Name = AXP3_CFTVM1 ______Protocol PeSITany = 1761 Protocol PeSITSSL = 1762 Comm. Synchronous = 1765 CFT User Interface = 1766 ______Connectivity to Composer, Sentinel, Passport or Navigator is not set. * Modify a parameter ...... Y/N? [N]: * Ready to install - confirm Y/N? [Y]: %CFT-I-COFFEEBREAK, Installation in progress. Please wait... %VMSINSTAL-I-RESTORE, Restoring product save set B ... %VMSINSTAL-I-RESTORE, Restoring product save set C ... %VMSINSTAL-I-RESTORE, Restoring product save set D ... %CFT-I-UPDATEACCOUNT, Updating the CFTVM1 account. [………] ************************************************************** ********* * CFT INSTALLATION COMPLETED. * * You can log on to the CFTVM1 account, * * check that the CFTLOGIN.COM procedure was correctly executed. * ************************************************************** ********* %VMSINSTAL-I-MOVEFILES, Files will now be moved to their target directories... Installation of CFT V3.3 completed at 11:10
Transfer CFT OpenVMS 3.3.2 Installation Guide 33 2 Install
Adding history entry in VMI$ROOT:[SYSUPD]VMSINSTAL.HISTORY Creating installation data file: VMI$ROOT:[SYSUPD]CFT033.VMI_ DATA VMSINSTAL procedure done at 11:10
Example
The contents of the generated SYS$UPDATE:CFT033.ANS file resemble the following example file.
* Number of groups using CFT [1]: \ * Name of Transfer CFT account [CFTVMS]: \CFTVM1 * Do you want to update the profile [Yes]: \ * Do you wish to continue [Yes]: \ * Maximum of simultaneous transfers (all networks) [32]: \ * Maximum of file sub-processes [8]: \ * Maximum of transfers per file sub-process [8]: \ * Number of transfers in SNA mode [0]: \ * Name of the batch queue used by CFT [SYS$BATCH]: \ * for the transfer owner user [No]: \Y * Single host(1) - Multiple Hosts(2)...... [1]: \ * Installation Directory [DKB0:[CFTVM1]]: \DKB0:[CFTVM1.TEST] * Confirm that you wish to install CFT in DKB0:[CFTVM1.TEST] [No]: \Y * Enable the multi-node architecture Y/N [N]: \Y * Number of nodes ...... [2]: \3 * Group Name ...... [Production.VMS]: \ * Local Name ...... [AXP3_CFTVM1]: \ * Hostname [AXP3.LAB1.LAB.LOCAL.COMPANY.INT]: \ * The synchronous communication [1765]: \ * The PeSITany protocol ...... [1761]: \ * The PeSIT protocol using SSL .. [1762]: \ * Catalog file - nb of records.. [10000]: \1000 * Comm. file - nb of records .... [1000]: \ * Listening port ...... [1766]: \ * Transfer CFT Navigator Y/N? ...... [N]: \ * Sentinel Y/N? ...... [N]: \ * Composer Enabler Y/N? ...... [N]: \ * P K I with PassPort Y/N? ...... [N]: \ * Access Management - PassPort Y/N? [N]: \ * Modify a parameter ...... Y/N? [N]: \
Transfer CFT OpenVMS 3.3.2 Installation Guide 34 2 Install
Deploy and install the ExpressPackage To deploy and install the ExpressPackage:
1. Create or import the product_name.ANS file in the sys$update directory. See Install and generate an ExpressPackage on page 29 for details. 2. Execute the new installation.
Note You must first delete or rename the existing answer file to create a new answer file when reinstalling Transfer CFT OpenVMS. After that execute the following command:
$@sys$update:vmsinstal cft033 DKB0:[TRANSFER_CFT_V3_3_2_VMS- ALPHA.INSTALL] OPTIONS A
Silent mode installation Silent mode, also referred to as the auto-answer option, enables you to perform a non-interactive installation where you do not need to manually enter parameters in the console.
To use silent mode, you must first install Transfer CFT OpenVMS and create a template answer file in your sys$update directory. You can then use this file to duplicate installations on other machines without repeatedly running the installer and entering the same parameters, as the silent mode takes the parameter values from existing or generated answer files.
For details and instructions, refer to Install and generate an ExpressPackage on page 29
Transfer CFT OpenVMS 3.3.2 Installation Guide 35 Post installation 3
Run Transfer CFT for the first time
Start/stop Transfer CFT This section describes the procedures for using Transfer CFT in an OpenVMS environment.
A full installation performs all the tasks needed to adapt the required files to your system.
The CFTLOGIN.COM procedure in the D$CFT_RUN:[PROFILE] directory is ready for use. You can customize or update this procedure if changes have been made to your operating environment. You are strongly advised to review this procedure so that you can familiarize yourself with the Transfer CFT environment.
If you have installed the product on an existing account, you must add a call to the CFTLOGIN.COM procedure in the login procedure of this account.
If the account does not already exist, the installation sequence gives you the option of using CFTLOGIN.COM as the login procedure.
The installation generates sample configuration files that provide information on Transfer CFT operations.
Start Transfer CFT This section describes how to start Transfer CFT for the first time for:
l A single Transfer CFT
l Multi-node Transfer CFT
After starting the server, refer to the Transfer CFT 3.0.1 VMS Operating Guide for information on how to run test loop transfers, make configuration changes, and enable options.
Start a single Transfer CFT instance Transfer CFT can be executed either in a batch mode or as a detached process.
In the CFTLOGIN.COM procedure, symbols are defined to simplify the start-up commands.
The CFT.com script is delivered in CFT_UTL directory and can be used to manage Transfer CFT. This script enables all supported Transfer CFT commands.
Transfer CFT OpenVMS 3.3.2 Installation Guide 36 3 Post installation
Usage: cft [Actions] [Options] Control the Transfer CFT component. Actions: start start Transfer CFT in the background stop stop Transfer CFT status display Transfer CFT status restart restart Transfer CFT force-stop kill Transfer CFT processes start-and-wait start Transfer CFT and wait for it to stop -h | --help display this help screen
l To start Transfer CFT in a batch queue, enter: $ cftstart
l To start the Transfer CFT as a detached process, enter: $ cft_d
l To start Copilot Server, enter: $ copstart
Sending transfer requests You can submit transfer requests if Transfer CFT is active.
To verify that Transfer CFT is active, enter the command:
$ show system/sub/batch/proc=cft*
Or
$ show system/OWNER_UIC=”YOUR_USER”
The processes making up Transfer CFT are displayed. In this example, Transfer CFT was submitted in batch mode.
OpenVMS V8.2-1 on node I64OV1 10-SEPT-2012 15:18:42.64 Uptime 0 02:11:43 Pid Process Name State Pri I/O CPU Page flts Pages 0000043A CFTMAIN_1C2 HIB 6 1369 0 00:00:00.19 1391 1578 B 0000043B CFTLOG_1C2 LEF 5 236 0 00:00:00.04 390 669 S 0000043C CFTTRK_1C2 HIB 5 251 0 00:00:00.07 1054 1217 S 0000043D CFTTCOM_1C2 HIB 6 36 0 00:00:00.03 357 525 S 0000043E CFTTPRO_1C2 HIB 6 101 0 00:00:00.04 672 898 S 0000043F CFTTCPS_1C2 LEF 4 438 0 00:00:00.05 495 648 S 00000440 CFTTFIL_1C2 HIB 6 42 0 00:00:00.04 443 788 S
Transfer CFT OpenVMS 3.3.2 Installation Guide 37 3 Post installation
To submit a command to Transfer CFT you can use CFTUTIL, Copilot or the API programming interfaces.
Shut down Transfer CFT To shut down Transfer CFT, enter the command:
$ cftutil shut fast=yes
or
$ cftstop
CFTV4_AXP2> cftstop CFTU20I CFTU20I CFT/VMS CFTU20I Version 3.0.1 09/09/2012 CFTU20I (C) Copyright AXWAY 1989-2012 CFTU20I ====> Starting Session on 23/10/2012 Time is 17:18:22 CFTU20I CFTU00I SHUT _ Correct (fast=yes) CFTU20I Number of Command(s) 1 CFTU20I Number of error(s) 0 CFTU20I Ending Session on 23/10/2012 Time is 17:18:22 CFTU20I Session active for 0:00:00 CFTV4_AXP2> Job CFTMAIN (queue SYS$AXP2, entry 733) completed
l Any transfers in progress are interrupted before Transfer CFT shuts down.
l The message CFTE09I CFT stop complete is displayed when the Transfer CFT processing has stopped.
l To shut down Copilot Server, enter the command: $ copstop
Shutting multi-node Transfer CFT instances Multi-node, multiple commands are available to stop Transfer CFT.
l To stop all nodes must run the command: $ cft stop
l You can manually stop the nodes, node by node, using the command: $ cft stop -n
l To shut down Copilot Server, enter the command: $ copstop
Example
For example, to stop node 0 execute the command: $cft stop –n 0
Transfer CFT OpenVMS 3.3.2 Installation Guide 38 3 Post installation
Any transfers in progress are interrupted before Transfer CFT shuts down. The message CFTE09I CFT stop complete is displayed when the Transfer processing has stopped.
Use the Copilot server This section describes the procedures required to use the Copilot server. It explains how to:
l Configure the server
l Administer the server
l Start and shut down the server
The connection between the Copilot server and the Copilot client is established via the TCP/IP protocol. Additionally, the Copilot server and Transfer CFT must be running on the same account.
Start the Copilot server To start the Transfer CFT Copilot server, enter the command: $copstart
Copilot executables The copstart command starts the COPSMNG.EXE executable, which launches the n sub- process. The COPSPROC.EXE image is used to create the sub-process and sets the listening port to the available status.
In the unified configuration, UCONF, set the Copilot configuration values.
copilot.general.enable = 'Yes'
Upon receiving a COPSMNG call, the call is acknowledged and transmitted to the first free COPSPROC sub-process. If no sub-process is available a new sub-process is created.
Example
Pid Process Name State Pri I/O CPU Page flts Pages 00002F99 copsproc_COP_3 LEF 6 268 0 00:00:00.08 223 317 S 00002F9A copsproc_COP_4 LEF 6 267 0 00:00:00.08 240 302 S 00002B9B COPSMNG_153413 LEF 6 33588 0 00:00:04.83 526 340 B 00002F9C copsproc_COP_5 LEF 6 268 0 00:00:00.08 256 265 S
Transfer CFT OpenVMS 3.3.2 Installation Guide 39 3 Post installation
Configure the Copilot server
Shut down the Copilot server The request to shut down the Copilot server is: $copstop –f
Copilot user rights To connect to the Copilot server, the client needs to provide a username and password. The username and password combination must correspond to a valid OpenVMS account. Additionally the account must have a Copilot identifier.
To define user rights in Copilot, use the authorize utility as follows.
Example
$ run authorize GRANT/IDENTIFIER COPILOT ‘user‘
Starting multi-node Transfer CFT instances In multi-node, the commands are similar to a single instance of Transfer CFT. For some command such as START or STOP, you can specify the node number.
Usage: cft [Actions] [Options] Control the Transfer CFT component. Actions: start start all nodes start -n
Transfer CFT OpenVMS 3.3.2 Installation Guide 40 3 Post installation
remove_node -n
l To start Transfer CFT multi node, you must first start the Copilot server. Enter the command: $ copstart
l Before starting Transfer CFT, activate nodes one by one using the command: $ cft enable_ node -n
l To start all Transfer CFT nodes, run the command: $ cft start
l You can also start a node using the node number by entering the command: $ cft start –n
Example
cft start –n 0
Transfer CFT OpenVMS environment
Transfer CFT environment This section describes the standard environment created by the installation procedure that is supplied in the Transfer CFT 3.3.2 VMS installation kit.
The standard Transfer CFT environment comprises a specific directory structure, which is supplied as a model. You can modify the file organization if required.
In the supplied CFTLOGIN.COM procedure in the full installation, each directory is redefined with a logical name. Likewise, symbols enable you to navigate from one directory to another.
Transfer CFT OpenVMS 3.3.2 Installation Guide 41 3 Post installation
l The CFTLOGIN.COM procedure is located in the d$cft_run:[profile].
l The d$cft_run:[profile]CFTLOGIN.COM procedure is used to ensure compatibility with previous versions of Transfer CFT.
To simplify reading, the logical name is used in this guide.
Default directory contents The default directory contents described in this section are provided as a general reference. The sample in this section corresponds to Transfer CFT version 3.3.2. The exact directory contents may vary according to the Transfer CFT version.
Sample configuration directory This directory contains the configuration samples and various files used by CFTUTIL.
D$CFT_RUN:[CONF] => CFT_SCEN logical directory
File Contents
CFT-PKI.CONF PKI parameter file.
CFT-TCP-PART.CONF File containing the sample partners’ configuration file generated by the installation procedure and used as the basic configuration to start CFT to quickly check the correct installation.
CFT-TCP.CONF File containing the sample configuration file generated by the installation procedure and used as basic configuration to start Transfer CFT.
CFT.KEY Contains the keys used by Transfer CFT.
CFT_RESET.PARM Samples to remove all files used by Transfer CFT (PARM, PART, CAT, COM, LOG, ACCNT).
DSPCNF.XML Model for the CFTUTIL DISPLAY command.
EXAM.CSV Sample of access management rules.
EXAM_LONG.CSV Sample of access management rules.
TRKAPI_ Samples used for the Sentinel heartbeat. TEMPLATE.CFG
Transfer CFT OpenVMS 3.3.2 Installation Guide 42 3 Post installation
Transfer CFT start procedure directory The following table describes the D$CFT_INST:[DISTRIB.SCRIPT]=> CFT_UTL logical directory which contains the procedures used to generate, configure, and start Transfer CFT VMS.
D$CFT_INST:[DISTRIB.SCRIPT] => CFT_UTL directory
File Contents
ADX_CONNECT.COM ADX profile.
CFT.COM Procedure for using Transfer CFT such as start, stop, and multi-node usage.
CFTDAT.COM Transfer CFT configuration procedure used to build the CFT execution environment from a text configuration file, such as those in the CFT_SCEN: directory.
CFTMAIN.COM Transfer CFT startup procedure. It is submitted in batch mode or as a detached process to start the Transfer CFT.
CFTMAIN_D.COM Procedure used to create a detached process with the CFTMAIN.COM procedure.
CFTUCONF.COM CFTUCONF procedure to get a specific UCONF configuration value.
CFTUCONF.FDL List of FDL attributes and their assigned values for the CFTUCONF file.
COP_WLOG.COM Procedure to send a message to the LOG Transfer CFT.
COPCFTSTART.COM Procedure to call COPILOT to restart Transfer CFT.
LOG.FDL List of FDL attributes and their assigned values for LOG file.
MIGRER24.COM Migration procedure.
TRACE.COM Trace start procedure.
SOFTKEY.COM Procedure used to determine the elements to be transmitted to your Transfer CFT Technical Support Team to obtain a software key.
XLATE.COM Procedure used to create/modify the conversion files used by Transfer CFT.
XLATE.DOC XLATE.COM procedure user guide.
Transfer CFT OpenVMS 3.3.2 Installation Guide 43 3 Post installation
Example procedures directory The D$CFT_RUN:[EXEC] => CFT_PROC logical directory contains sample procedures that were submitted by Transfer CFT for certain events.
File Contents
EM_ERR.PRO Procedure submitted when a send error is detected.
EM_FIC.PRO Procedure submitted after a file has been sent.
EM_FIC_ACK.PRO Procedure submitted when a file send acknowledgement is received.
EM_MESS.PRO Procedure submitted after a message has been sent.
EM_MESS_ACK.PRO Procedure submitted when a message send acknowledgement is received.
REC_ERR.PRO Procedure submitted when a receive error is detected.
REC_FIC.PRO Procedure submitted after a file has been received.
REC_MESS.PRO Procedure submitted after a message has been received.
VIDACCNT.PRO Procedure submitted when an ACCOUNT. file is switched and is used to purge this file.
ROTATE.PRO Procedure submitted when a LOG. file is switched and is used to purge this file.
Building the Transfer CFT environment After installation, you must configure Transfer CFT to declare the:
l Network environment
l Partners with which you wish to perform transfers
l Actions to trigger for each event
Mandatory files
Transfer CFT behavior is determined by the contents of two indexed files, the PARAMETER and the PARTNER file. Transfer CFT uses a direct file, the CATALOG, to record the transfer-related information. These three files are mandatory.
Optional files
Optional environment files include:
Transfer CFT OpenVMS 3.3.2 Installation Guide 44 3 Post installation
l COMMUNICATION: required to use file-based communication
l LOG: used to record all Transfer CFT events
l ACCOUNT: used to record all information concerning terminated transfers
For more information, refer to the Transfer CFT 3.0.1 User's guide or online help.
Configuration files CFT_SCEN: directory The CFT_SCEN: directory contains a set of basic Transfer CFT configuration files.
l cft-tcp.conf: File containing the sample partners’ configuration
l cft-tcp-part.conf: File containing the sample configuration
To configure Transfer CFT, you must create your own configuration file. For more information, refer to the Transfer CFT online documentation.
To interpret the parameter files, use the following command:
$cftinit cft_scen:cft-tcp.conf cft_scen:cft-tcp-part.conf
This procedure also purges directories, creates the files used by Transfer CFT (PARAMETER, PARTNER, CATALOG, COMMUNICATION, LOG and ACCOUNT), and analyzes the contents of the file passed as a parameter to update the PARAMETER and PARTNER files.
Generating a test Transfer CFT
Create a test Transfer CFT To generate a test Transfer CFT, enter the command: $cftinit cft_scen:cft-tcp.conf
The following messages are displayed:
CFTU20I CFTU20I CFT/VMS CFTU20I Version 3.0.1 09/09/2012 CFTU20I (C) Copyright AXWAY 1989-2012 CFTU20I ====> Starting Session on 09/09/2012 Time is 13:58:32 CFTU20I CFTU00I CFTFILE _ Correct (TYPE=PARAM,FNAME=CFTPARM) CFTU00I CFTFILE _ Correct (TYPE=PART,FNAME=CFTPART) CFTU00I CFTFILE _ Correct (TYPE=CAT,FNAME=CFTCATA,RECNB=600) CFTU00I CFTFILE _ Correct (TYPE=COM,FNAME=CFTCOM,RECNB=50) CFTU00I CFTFILE _ Correct (TYPE=LOG,FNAME=CFTLOG) CFTU00I CFTFILE _ Correct (TYPE=LOG,FNAME=CFTLOGA) CFTU00I CFTFILE _ Correct (TYPE=ACCNT,FNAME=CFTACCNT)
Transfer CFT OpenVMS 3.3.2 Installation Guide 45 3 Post installation
CFTU00I CFTFILE _ Correct (TYPE=ACCNT,FNAME=CFTACCNTA) CFTU00I RETURN _ Correct (CODE=0) CFTU20I Number of Command(s) 8 CFTU20I Number of error(s) 0 CFTU20I Ending Session on 23/10/2006 Time is 16:43:47 CFTU20I Session active for 0:00:10 CFTU20I CFT/VMS CFTU20I Version 3.0.1 09/09/2012 CFTU20I (C) Copyright AXWAY 1989-2012 CFTU20I ====> Starting Session on 09/09/2012 Time is 13:59:32 CFTU20I Parameters file :CFTPARM CFTU20I Partners file :CFTPART CFTU20I Catalog file :CFTCATA CFTU20I CFTU00I CFTPARM _ Correct (id=IDPARM0,default=IDFDEF,KEY=@CFT_ DAT:CFTKEY.PARM) CFTU00I CFTCOM _ Correct (id=com0,type=file,name=CFTCOM,wscan=1,mode=REPLACE) CFTU00I CFTCOM _ Correct (id=coms,type=tcpip,protocol=xhttp,host=127.0.0.1,p) CFTU00I CFTCAT _ Correct (id=cat0,fname=CFTCATA,wscan=1,updat=1,mode=REPLACE) CFTU00I CFTLOG _ Correct (ID=LOG0,AFNAME=CFTLOGA,EXEC=CFT_ PROC:VIDLOG.PRO,FN) CFTU00I CFTACCNT _ Correct (ID=ACCNT0,TYPE=FILE,AFNAME=CFTACCNTA,EXEC=CFT_PROC) CFTU00I CFTNET _ Correct (id=NET0,maxcnx=128,type=TCP,host=INADDR_ ANY,call=I) CFTU00I CFTPROT _ Correct (id=PESITANY,net=NET0,type=PESIT,prof=ANY,sap=17610) CFTU00I CFTPROT _ Correct (id=PESITSSL,net=NET0,type=PESIT,prof=ANY,sap=17620) CFTU00I CFTSSL _ Correct (id=SSLPESIT,direct=SERVER,rootcid= (AXWMFTCA),userc) CFTU00I CFTSEND _ Correct (id=IDFDEF,fcode=BINARY,fname=CFT_ SEND:TEST.SND,mod) CFTU00I CFTRECV _ Correct (id=IDFDEF,fcode=BINARY,fname=CFT_RECV:&IDF_ &IDT.RE) CFTU00I CFTSEND _ Correct (id=BIN,fcode=BINARY,fname=CFT_ SEND:TEST.SND,mode=R) CFTU00I CFTRECV _ Correct (id=BIN,fcode=BINARY,faction=delete,fname=CFT_RECV:) CFTU00I CFTSEND _ Correct
Transfer CFT OpenVMS 3.3.2 Installation Guide 46 3 Post installation
(id=TXT,fcode=ASCII,fname=CFT_SEND:TEST.SND,mode=RE) CFTU00I CFTRECV _ Correct (id=TXT,fcode=ASCII,faction=delete,fname=CFT_ RECV:&) CFTU00I CFTSEND _ Correct (id=FIC1,exit=ID_EXIT,fname=CFT_ SEND:TEST.SND,mode=) CFTU00I CFTEXIT _ Correct (id=ID_ EXIT,language=C,prog='CFTEXITF',reserv=100,f) CFTU00I CFTSEND _ Correct (id=ID_ EXITL,exit=CFTEXLST,impl=yes,faction=delete,) CFTU00I CFTEXIT _ Correct (id=CFTEXLST,language=C,prog='CFTEXL',reserv=8192,f) CFTU00I CFTAPPL _ Correct (id=IDFDEF,direct=both,userid=&userid)v CFTU00I RETURN _ Correct (CODE=0) CFTU20I Number of Command(s) 21 CFTU20I Number of error(s) 0 CFTU20I Ending Session on 09/09/2012 Time is 13:59:32 CFTU20I Session active for 0:00:00
Create sample partners To create sample partners, enter the command: $ cftinit cft_scen:cft-tcp-part.conf
The following procedure creates the sample partners:
l loop transfer: partners Paris - New York
l loop transfer using SSL: loopssl
CFTU20I CFTU20I CFT/VMS CFTU20I Version 3.0.1 09/09/2012 CFTU20I (C) Copyright AXWAY 1989-2012 CFTU20I ====> Starting Session on 09/09/2012 Time is 13:57:39 CFTU20I Parameters file :CFTPARM CFTU20I Partners file :CFTPART CFTU20I Catalog file :CFTCATA CFTU20I CFTU00I CFTPART _ Correct (id=NEWYORK,prot=PeSITANY,sap=17610,nspart=PARIS,nr) CFTU00I CFTTCP _ Correct (id=NEWYORK,host=127.0.0.1,cnxin=8,cnxout=8,cnxinou) CFTU00I CFTPART _ Correct (id=PARIS,prot=PeSITANY,sap=17610,nspart=NEWYORK,nr) CFTU00I CFTTCP _ Correct
Transfer CFT OpenVMS 3.3.2 Installation Guide 47 3 Post installation
(id=PARIS,host=127.0.0.1,cnxin=8,cnxout=8,cnxinout=) CFTU00I CFTPART _ Correct (id=LOOP,prot=PeSITANY,sap=17610,nspart=LOOP,nrpart) CFTU00I CFTTCP _ Correct (id=LOOP,host=127.0.0.1,cnxout=8,cnxin=8,cnxinout=8) CFTU00I CFTPART _ Correct (id=LOOPSSL0,prot=PESITSSL,sap=17620,nspart=LOOPSSL) CFTU00I CFTTCP _ Correct (id=LOOPSSL0,host=127.0.0.1,cnxout=8,cnxin=8,cnxino) CFTU00I CFTSSL _ Correct (id=SSL_LOOP0,direct=CLIENT,rootcid= (AXWMFTCA),pass) CFTU00I RETURN _ Correct (CODE=0) CFTU20I Number of Command(s) 9 CFTU20I Number of error(s) 0 CFTU20I Ending Session on 09/09/2012 Time is 13:57:39 CFTU20I Session active for 0:00:00
The Transfer CFT environment is now built and ready for use.
About submitting commands To begin submitting commands to Transfer CFT you can use:
l CFTUTIL
l Copilot
l API programming interfaces
For more information, see communications.
Transfer CFT environment directory The D$CFT_RUN:[DATA] => CFT_DAT logical directory is used to store the files needed for the Transfer CFT environment, as well as the data files used by the XLATE.COM utility.
As described in Generating a test Transfer CFT, the following files are created by running CFTDAT in CFTUTIL:
cftinit cft_scen: cft-tcp.conf cft_scen: cft-tcp-part.conf
Transfer CFT OpenVMS 3.3.2 Installation Guide 48 3 Post installation
File Contents
CFTUCONF.DAT The Transfer CFT client configuration file. This file is delivered in the installation, and then customized by the user during installation.
CFTCATA.REL The Transfer CFT CATALOG file.
CFTCOM.REL The Transfer CFT COMMUNICATION file.
CFTPARM.INX The Transfer CFT PARAMETER file.
CFTPART.INX The Transfer CFT PARTNER file.
Certificate directory This directory contains the certificates (*.DER, *.P12) is: D$CFT_RUN:[CONF.PKI] => CFT_PKI logical directory.
Transfer CFT log file directory The D$CFT_RUN:[LOG] =>CFT_LOG logical directory is used to store Transfer CFT log files.
File Contents
CFTLOG.LOG The Transfer CFT LOG file. This file is not supplied. It is created by CFTUTIL in the CFTDAT procedure.
Transfer CFT log account directory The D$CFT_RUN:[ACCNT]=> CFT_ACCNT logical directory is used to store Transfer CFT account files.
File Contents
CFTACCNT.LOG Transfer CFT ACCOUNT file. This file is not supplied. It is created by CFTUTIL in the CFTDAT procedure.
CFTACCNT.LOGA Transfer CFT ACCOUNT file. This file is not supplied. It is created by CFTUTIL in the CFTDAT procedure.
Transfer CFT OpenVMS 3.3.2 Installation Guide 49 3 Post installation
Files to send directory The D$CFT_RUN:[PUB] => CFT_SEND logical directory used to store the files to be sent in the sample configurations.
File Contents
TEST.SND Variable sequential file.
FTEST.SND Variable sequential file.
Rebuild Transfer CFT directory The D$CFT_INST:[LIB]=> XMKT_BDIR:[LIB] directory contains the libraries and objects required to rebuild Transfer CFT.
Link the Transfer CFT image directory The D$CFT_INST:[OPT]=> XMKT_BDIR:[OPT] directory contains procedure used to link Transfer CFT.
File Contents
CFT_LINK.COM Procedure used to link the Transfer CFT images. The installation performs the link operation, but this procedure can be used if the VMS release is changed, for example.
COP_LINK.COM Procedure used to link the COP images. The installation performs the link operation, but this procedure can be used if the VMS release is changed, for example.
MJGBLCFT.COM Cf: CFT GLOBALS SECTION
*.OPT Option files used to build the Transfer CFT images and associated utilities.
Transfer CFT image directory Transfer CFT image directory.
The logical name CFT_EXE points to the D$CFT_INST:[bin]directory.
Example Transfer CFT directory This directory contains program samples in C that describe how to use Transfer CFT APIs and Exits.
Transfer CFT OpenVMS 3.3.2 Installation Guide 50 3 Post installation
There are two logical names:
l CFT_EXIT, which points to D$CFT_RUN:[SRC] directory
l CFT_API, which points to D$CFT_RUN:[SRC] directory
This directory is comprised of two subdirectories, CAPI and EXIT, as described in the next sections.
The subdirectory D$CFT_RUN:[SRC.CAPI] provides the following Transfer CFT files and samples.
File Contents
API2XMP1.C The catalog API sample program listing all catalog content.
API2XMP2.C The catalog API sample program, which changes all Terminated (X) transfers to Ended.
APIXMP1.C C API LIST for the catalog samples.
APIXMP2.C C API commands: Send, Recv, Halt samples.
EXACCT.C C samples for the account file.
IPCAI2.C C API samples.
TCFTAIX.C IPC test program.
TCFTSYN.C The communication and catalog API sample program. For example, you can use this API program to display the CATALOG.
The subdirectory D$CFT_RUN:[SRC.EXIT] provides the following Transfer CFT files and samples.
File Contents
EXAMLDAP.C;1 Access Management exit with LDAP sample.
EXAMRBAC.C;1 Access Management exit sample.
EXAMRBAC.H;1 Header used for sample exit.
EXAMSMP1.C;1 Access Management exit sample.
EXAXMP1.C;1 DIRECTORY TYPE EXIT TASK example.
EXEXMP1.C;1 END-OF-TRANSFER TYPE EXIT TASK V240 example.
EXFXMP1.C;1 EXAMPLE OF FILE TYPE EXIT TASK V240, which writes a message in the Transfer CFT log file for each transfer stage.
EXFXMP2.C;1 EXAMPLE OF FILE TYPE EXIT TASK V240.
Transfer CFT OpenVMS 3.3.2 Installation Guide 51 3 Post installation
Example Transfer CFT exit directory Directory containing program samples in C that describe how to use Transfer CFT APIs.
Logical name CFT_EXIT points to D$CFT:[CFT.RUNTIME.SRC] directory. There are two subdirectories : CAPI and EXIT.
File Contents
*.OPT File containing the link options for the various samples provided.
CFTEXITL.COM Procedure submitted by an exit and used to query the remote catalog.
EXFXMP2.C Sample FILE EXIT program written in C.
EXAXMPM.C Samples of DIRECTORY EXIT programs written in C. EXAXMPP.C
EXEXMP1.C Sample END OF TRANSFER EXIT program written in C.
EXEUS.H C include file required to develop an END OF TRANSFER EXIT program.
EXFUS.H C include file required to develop a FILE EXIT program.
EXAUS.H C include file required to develop a DIRECTORY EXIT program.
EXEUS. Declaration file required to develop an END OF TRANSFER EXIT program in COBOL.
Submit Transfer CFT OpenVMS procedures A number of logical names are used to configure the Transfer CFT behavior with respect to the various procedures submitted by it. For more information, refer to the MONIT_MEM utility section.
The following table describes the logical names for the procedures that control Transfer CFT behavior.
Logical Description Name
CFT_QUEUE This logical name designates the name of the batch queue, in which the monitor submits the various procedures that it controls. It must be defined with the /JOB attribute.
Transfer CFT OpenVMS 3.3.2 Installation Guide 52 3 Post installation
Logical Description Name
CFT_SUBMIT This logical name defines the behavior of the monitor when it submits an end of transfer procedure. If the logical name is set to USER, the procedures are submitted from the transfer owner account.
CFT_PRINT This logical name is used to define a print queue, via which the procedure execution reports are printed. It must be defined with the /JOB attribute.
CFT_LOGDEL When set to YES, this logical name is used to request VMS to delete the execution reports of the procedures that it submits. Any other value maintains the reports in the SYS$LOGIN directory. It must be defined with the /JOB attribute.
Controlling memory usage Logical names are used to control Transfer CFT memory bottlenecks, refer to the Delivered components section. The following table describes the logical names that are used to control Transfer CFT OpenVMS memory.
Logical Meaning Name
CFT$MEMCSTE This logical name is used to define the amount of memory used by the monitor images in the Transfer CFT VMS JOB. Its default value is 1 100 000.
CFT$CATA This logical name is used to define the percentage of available memory, as from which the monitor implements the bottleneck control mechanism. Its default value is 80.
CFT$COOL This logical name is used to define the percentage of available memory, as from which the monitor is no longer in the alert status triggered by CFT$CATA. Its default value is 70.
CFT$MEMDLAY This logical name is used to define a period after the monitor is no longer in the alert status, during which the monitor refuses any new incoming or outgoing connections, so that it can process the data already received.
CFT$MG_NB This logical name is used to define the number of 16-KB buffers reserved by Transfer CFT VMS in the global section. See section 5.4
Transfer CFT OpenVMS 3.3.2 Installation Guide 53 3 Post installation
Transfer CFT to operator messages The CFTLOG command NOTIFY parameter is used to designate the operator where LOG messages are sent. These messages are processed differently, according to the syntax used for the NOTIFY parameter. Two possibilities are available, user name or hexadecimal value.
l The NOTIFY parameter value is a user name. The messages intended for the operator are sent to all of the terminals on which the user is logged. Each message is displayed on the last line of the terminal. A new message overwrites the previous one. To stop receiving these messages on a particular terminal, enter the command: $ set terminal/nobroadcast
To restart this message delivery, use the command: $ set terminal/broadcast
l The NOTIFY parameter value has the OPnnnnnn format, where nnnnnn represents a string of six hexadecimal digits. The messages are sent to an operator terminal. This string determines the type of terminal to receive the messages. It corresponds to the OPC$B_MS_TARGET field of the SYS$SNDOPR system service request block. For more information, refer to the OpenVMS System Services Reference Manual.
To receive messages, enter the REPLY/ENABLE=XXX command, where XXX represents the selected operator class.
Example
$ reply/enable=oper1
Hexadecimal values for the operator classes
Symbolic Name Hexadecimal Mask Decimal Value
OPC$M_NM_CENTRL 1 1
OPC$M_NM_PRINT 2 2
OPC$M_NM_TAPES 4 4
OPC$M_NM_DISKS 8 8
OPC$M_NM_DEVICE 10 16
OPC$M_NM_CARDS 20 32
OPC$M_NM_NTWORK 40 64
OPC$M_NM_CLUSTER 80 128
OPC$M_NM_SECURITY 100 256
OPC$M_NM_OPER1 1 000 4 096
Transfer CFT OpenVMS 3.3.2 Installation Guide 54 3 Post installation
Symbolic Name Hexadecimal Mask Decimal Value
OPC$M_NM_OPER2 2 000 8 192
OPC$M_NM_OPER3 4 000 16 384
OPC$M_NM_OPER4 8 000 32 768
OPC$M_NM_OPER5 10 000 65 536
OPC$M_NM_OPER6 20 000 131 072
OPC$M_NM_OPER7 40 000 262 144
OPC$M_NM_OPER8 80 000 524 288
OPC$M_NM_OPER9 100 000 1 048 576
OPC$M_NM_OPER10 200 000 2 097 152
OPC$M_NM_OPER11 400 000 4 194 304
OPC$M_NM_OPER12 800 000 8 388 608
System specific functions
System environment This section describes the Transfer CFT architecture, the resources used, and the methods for controlling the Transfer CFT behavior in an OpenVMS environment.
Transfer CFT processes Transfer CFT is made up of a JOB that contains several processes. When a job is activated, a CFTMAIN process is created, either in batch mode or as a detached process, and creates sub- processes itself. All these processes are executed with the same UIC as the account in which Transfer CFT was installed and share two global memory sections.
Transfer CFT contains several processes, each of which has standard output files corresponding to SYS$OUTPUT and SYS$ERROR. These files are created in SYS$LOGIN and are named:
And
Transfer CFT OpenVMS 3.3.2 Installation Guide 55 3 Post installation
Where:
l
l CFT_process is the Transfer CFT process name
l XX is the group UIC number displayed in hexadecimal
These files can only be accessed in read mode after you have shut down Transfer CFT. Transfer CFT creates a new version each time it is started. These files are very important for troubleshooting in the event of a problem. Keep them following an incident, so that you can provide this information to the Technical Support Team.
During normal operations, these files may accumulate each time Transfer CFT is restarted. The administrator must delete these periodically, so that the disk is not unnecessarily saturated.
Inter-process communication Transfer CFT processes inter-communicate using the shared memory and two global sections, which can be seen by all users in the same group.
Each process using Transfer CFT-specific inter-process communication functions is automatically associated with these two global sections.
The names of the two global sections are:
l CFT_XX
l CFT3_XX
Where XX represents the USER group number in hexadecimal.
In the system, the corresponding parameters are as follows:
l GBLPGFIL represents the number of global pages that can be created on the system
l GBLSECTIONS represents the number of sections that can be created on the system
Transfer CFT creates approximately 2,000 global pages and two global sections.
Even if they do not use the same communication, the CFTUTIL and the APIs are attached to the global sections when initialized.
Transfer CFT global sections For internal communication requirements, Transfer CFT uses shared memory buffers, which are created in the second global section, and are called CFT3_XX.
By default, Transfer CFT defines 30 16-KB buffers during its startup sequence. Depending on the requirements, these buffers are broken down into smaller blocks. Transfer CFT reserves 960 global pages by default for this purpose, which may be either excessive or insufficient, depending on the average Transfer CFT activity.
Transfer CFT OpenVMS 3.3.2 Installation Guide 56 3 Post installation
The default value may be modified using the CFT$MG_NB logical name, which indicates the number of 16-KB buffers that Transfer CFT reserves during its startup sequence. If you modify the default value, Transfer CFT reserves more or fewer global pages on the system, which allows you to adapt Transfer CFT to your production constraints.
During the Transfer CFT installation the binary files are generated by default. In the binaries, the value for Transfer CFT $ MGNB must fall in the range of 30 to 90.
The MJGLBCFT.COM utility enables you to modify default values and define value limitations. After making a modification, you must regenerate the binaries. See Rebuild Transfer CFT Directory.
Example:
@ <.opt>MJGLBCFT.COM ‘minimum value’ ‘maximum value’ CFT_LINK @<.opt>CFT
Note Remember to modify the startup account parameters for Transfer CFT accordingly. ADD LINK TO PARM
Manage Transfer CFT memory During transfers, the data in a file from the network is buffered by the CFTTPRO task while waiting for the CFTTFIL task to write the corresponding records to the disk.
At the same time, Transfer CFT accepts all the data from the network without any flow control. PeSIT and ODETTE can implement this control at protocol level.
In some operating conditions, the disks may be accessed intensively. Applications requiring frequent access to the disk are particularly affected when the BACKUP utility is used.
By default CFTTFIL uses the RMS parameters that are defined at the system level.
l Logical names CFT$MBCNT and CFT$MBFCNT enable you to modify the default values.
l CFT$MBCNT: Specifies a multi-block count (0 to 127) only for I/O record operations, where count is the number of blocks allocated for each I/O buffer
l CFT$MBFCNT: Specifies a default multi-buffer count (0 to 255) for local file operations, where count is the number of buffers to be allocated
Data from the network is buffered in dynamic memory, which is allocated by the CFTTPRO task as necessary. The quantity of memory that can be allocated by a JOB is determined by the PGFLQUOTA parameter associated with the user. It represents the total memory space that can be reserved by this JOB, including the images and stack.
If an excessive amount of data is buffered by the CFTTPRO task following a file access bottleneck, the task lacks sufficient memory and the system can no longer satisfy memory allocation requests. When this situation occurs, the sub-processes are shut down and the monitor is blocked.
Transfer CFT OpenVMS 3.3.2 Installation Guide 57 3 Post installation
You must allocate sufficient memory to Transfer CFT to prevent this problem from occurring. The maximum amount of memory likely to be used for the JOB, in the extreme case of disk access saturation, is calculated as Sum of the size of all JOB images plus approximately 10%.
However, according to your configuration and the networks involved, some images are used and some are not (in particular, the CFTLOG and CFTTCOM tasks, the various network server tasks and the maximum number of CFTTFIL tasks).
You must also include the data from the network for each receive file. The maximum amount of buffered data per transfer depends on the type of protocol:
l ODETTE: size of the network exchanges (CFTPROT RRUSIZE parameter) multiplied by the credit (CFTPROT RCREDIT parameter)
l PeSIT: synchronization interval (CFTPROT RPACING parameter) multiplied by the synchronization window (CFTPROT RCHKW parameter)
If there is a low risk of the disk accesses being saturated on your system or the amount of memory that can be allocated to Transfer CFT is limited, you can specify a much lower value than the one provided above.
Transfer CFT is equipped with an internal configurable mechanism, which prevents it from reaching an insufficient memory status.
When the data from the network greatly exceeds the disk write capacities, Transfer CFT closes certain sessions before reaching the memory saturation threshold until the correct balance is established. New session requests are refused until Transfer CFT has resolved the bottleneck problems, while enabling it to terminate the remaining transfers in progress.
Transfer CFT behavior is determined using the value assigned to the following logical names.
l CFT$MEMCSTE This logical name corresponds to the number of bytes used by the various monitor images. Its value is calculated according to the first part of the formula described above. The logical name is used to calculate the amount of memory that can still be allocated by the monitor. When the monitor is started up, the available memory is calculated as being equal to the number of pages that can still be reserved by the JOB in the page file, multiplied by 512, minus the value of CFT$MEMCSTE. The default value of this constant is 1 100 000 bytes.
l CFT$CATA This logical name corresponds to the percentage of remaining memory that can be allocated by Transfer CFT. Transfer CFT bases the regulation mechanism described above on this percentage. The default value of this constant is 70.
l CFT$COOL This logical name corresponds to the percentage of remaining memory that can be allocated by Transfer CFT. When this percentage is reached, Transfer CFT considers that it has resolved its memory congestion problems and stops closing sessions. The default value of this constant is 80.
l CFT$MEMDLAY This logical name corresponds to the period, during which Transfer CFT refuses to establish new connections after the memory status has returned to normal. The default value of this constant is 0000 00:10:00.00, which is 10 minutes.
All of these constants are set to their default value if the corresponding logical name is not defined.
Transfer CFT OpenVMS 3.3.2 Installation Guide 58 3 Post installation
MONIT_MEM utility The MONIT_MEM utility is used to track the Transfer CFT memory usage during processing. It displays the amount of memory that can still be allocated by the JOB, and the number and size of memory buffers shared between the tasks. It is used to fine-tune CFT$MEMCSTE, CFT$CATA, CFT$COOL and CFT$MG_NB.
Enter the command:
$run cft_exe:monit_mem
CFT GLOBAL MEMORY: 60/60
QUEUE 0 (00064 bytes) = 35 QUEUE 1 (00128 bytes) = 11 QUEUE 2 (00256 bytes) = 10 QUEUE 3 (00512 bytes) = 9 QUEUE 4 (01024 bytes) = 10 QUEUE 5 (02048 bytes) = 9 QUEUE 6 (04096 bytes) = 10 QUEUE 7 (08192 bytes) = 10 QUEUE 8 (16384 bytes) = 50
Available space in Bytes: 981568
CFT LOCAL MEMORY :
Available space in Bytes: 94192567
Init. threshold in Bytes: 23854496 Alarm threshold in Bytes: 23854496 Ready threshold in Bytes: 33397949
Transfer CFT procedures When batch procedures (end of transfer, log switching, and so on) are triggered, a temporary command file and its execution report file are created. These procedures are submitted in batch mode in the batch queue defined by the CFT_QUEUE logical name.
These submits cause a temporary file to be created in the directory in which the CTMAIN JOB is running:
CFT_XXXXXX_HHMMSS.COM
Transfer CFT OpenVMS 3.3.2 Installation Guide 59 3 Post installation
Where:
l XXXXXX = submitter's process ID in hexadecimal
l HHMMSS = timestamp
This file is deleted following normal procedure execution. An execution report is created in the SYS$LOGIN directory, with a default name of CFT_XXXXXX_HHMMSS.LOG.
Defining the CFT_PRINT logical name with the required print queue value can print these reports.
You can also specify that VMS must delete the reports of correctly executed procedures by setting the CFT_LOGDEL logical name to YES.
The end of transfer procedures, CFTPARM command EXEC* parameters, and CFTSEND and CFTRECV commands EXEC parameter, are submitted from the transfer owner account and not Transfer CFT. Users can therefore submit their own end of transfer procedures.
The Transfer CFT must have the CMKRNL privilege to submit a JOB from the account of another user. The installation procedure provides the option of implementing this mechanism.
A logical name value is used to define Transfer CFT behavior. Therefore when Transfer CFT is installed or subsequently during processing, the product operations manager must modify the CFTLOGIN.COM file so that the CFT_SUBMIT logical name can be set.
The authorized values are as follows:
l USER: The ends of transfer procedures are submitted from the transfer owner's account (command submitter in requester mode or USERID parameter value in server mode). Note that Transfer CFT must be able to obtain the CMKRNL privilege
l CFT: the end of transfer procedures are submitted from Transfer CFT owner's account
l Any other value is equivalent to CFT
Transfer CFT communications You can communicate with Transfer CFT using a file, a mailbox, or a TCP/IP connection.
Note When using a multi-node architecture, the mailbox and TCP/IP communication options are not available.
Communication file A communication file is a relative file created using the CFTUTIL or Copilot utility. It has a specific internal structure and must be accessible to all users wishing to submit requests to the monitor.
Mailbox The Transfer CFT mailbox concept coincides with the VMS Mailbox concept. It is designated by its logical name, which is defined in a table of logical names and must be visible to all users who need to submit requests to Transfer CFT.
Transfer CFT OpenVMS 3.3.2 Installation Guide 60 3 Post installation
TCP/IP connection A TCP/IP communication medium is asynchronous, or connected.
An application cannot submit a service request via a synchronous communication medium unless Transfer CFT is active; you must first establish a TCP/IP connection between application and Transfer CFT.
Transfer CFT supplies an execution report for each service request. Transfer CFT supplies additional data such as the unique identifier of the transfer for transfer requests (SEND and RECV). This identifier is used for tracking.
Transfer CFT parameter settings A communication media must be configured before starting Transfer CFT. The CFTCOM command defines the communication medium and its attributes (medium type, name, etc.).
CFTCOM ID= identifier, TYPE= {FILE | MBX | TCP }, TYPE= TCP PROTOCOL= {XHTTP | XHTTPS}, HOST = string, PORT = numéric , [ADDRLIST= (string,string…),] [DISCTS= numéric ,]
Use the Transfer CFT API commands The following service requests are specific to TCP/IP:
l GETXINFO retrieves the report and information relating to the last transfer request (SEND or RECV).
l CLOSEAPI frees system resources allocated by the command API.
To implement TCP/IP communication, you must:
l Configure Transfer CFT (CFTCOM command)
l Set the API command parameters (COM function)
COM function Use the COM function of the command API to force the communication medium, type and name, from an application.
For example, the CFTUTIL command CONFIG TYPE=COM calls the COM function to configure a communication medium.
Transfer CFT OpenVMS 3.3.2 Installation Guide 61 3 Post installation
Command API configuration file contents A configuration file is a text file. It contains lines of instructions with one instruction per line. A comment line must start with a hash character: #.
The following two parameters are mandatory:
l TYPE= {FILE | MAILBOX | TCP}
o Mandatory instruction used to declare the communication type.
l NAME= MediaName
o Mandatory instruction used to declare the name of the communication medium. Depending on the type, it is the name of the communication file or the name of the mailbox or, for synchronous communication, the complete name of the TCP/IP communication channel (protocol://host:port).
For a TCP/IP communication type (TYPE = TCP), the protocol field indicates the protocol implemented on the TCP/IP layer. For more information see the PROTOCOL parameter of the command CFTCOM. The protocol must correspond to the one declared on the monitor. The host field indicates the name of the host or the IP address of the machine where the Transfer CFT you want to reach is executing (local host only for machine-internal communication). The port field indicates the listening port of the Transfer CFT to contact.
Example of API configuration file:
# CFT API CONFIGURATION FILE # TCP/IP COMMUNICATION TYPE=TCP NAME=xhttp://localhost:5001
If a configuration file contains several communication medium definitions, the first definition is taken into account.
GETXINFO function Use this command API function to restore additional information that Transfer CFT returns for the SEND and RECV commands, via a structure of the type cftApiInf (file definition CFTAPI.H).
CLOSEAPI function Use this function to free system resources allocated by the command API (memory, network). It is strongly recommended that you call the CLOSEAPI function when the communication medium is TCP/IP.
Return code With TCP/IP, the command API returns a processing report (rc or CFTRC field of Z-RC).
Transfer CFT OpenVMS 3.3.2 Installation Guide 62 3 Post installation
CFTUTIL To use a TCP/IP communication media with Transfer CFT, you must first enter the CONFIG command.
CONFIG TYPE= {COM | … }, [MEDIACOM= {FILE | MBX | TCP},] FNAME= string
The MEDIACOM parameter is optional. It accepts the values FILE, MBX and TCP.
If the value of the MEDIACOM parameter is TCP, the FNAME parameter indicates the name of the communication channel (protocol://host:port). If the MEDIACOM parameter is absent, the FNAME parameter indicates the name of a configuration file.
Examples:
config type=com,mediacom=tcp,fname=xhttp://172.17.5.1:6550 config type=com,fname=cft231prd/conftcp
User group When a file is used to communicate, it is accessed by a number of concurrent processes in both the write and read modes. Concurrent access to this file is controlled through the DISTRIBUTED LOCK MANAGER. By default, it is enabled for the group.
If users belonging to different groups are likely to submit commands in the communication file, it must be locked at system level. Therefore, you must:
l Grant the SYSLCK privilege to Transfer CFT and all users writing in the communication file
l Set the CFT_LOCK logical name to SYSTEM for the job in the CFTLOGIN.COM procedure using the following command for example: $ define/job CFT_LOCK SYSTEM
Any value other than SYSTEM only locks the file at group level. Users from other groups then have uncontrolled access to the file, which consequently may affect the contents.
Concurrent access to the communication file If users belonging to a group other than the Transfer CFT group want to submit commands in the Transfer CFT communication file, you must enable the concurrent access control mechanism at system level. The CFT_LOCK logical name is used to implement this mechanism. For more information, see the Transfer CFT parameter settings section.
Transfer CFT OpenVMS 3.3.2 Installation Guide 63 3 Post installation
CFT_LOCK If the CFT_LOCK logical name is set to SYSTEM, the concurrent access control mechanism is enabled at system level. Otherwise, the control is performed at group level. The SYSLCK privilege is required to implement the mechanism. The logical name must be defined with the /JOB attribute.
Optimize receive file write operations When receiving files, Transfer CFT allows you to optimize the way in which they are written, by performing disk accesses in virtual block mode instead of requesting that RMS write each record. The CFT$BLOCKIO logical name is used to implement this mechanism. The increased performance levels are especially noticeable when writing files containing small-sized records.
CFT$BLOCKIO If this logical name is not defined or its substitution begins with the letter N, Transfer CFT writes the records received via RMS. In all other cases, the records are written in virtual block mode. The logical name must be defined with the /JOB attribute.
Multiple Transfer CFT instances on the same system Transfer CFT is installed in a specific user account. Only one Transfer CFT can be active per user group on the same system.
If you want to execute several Transfer CFT instances on the same system, they must be executed in different groups. The UICs should have the following format, where AAA and BBB are different values: [AAA,XXX] and [BBB,YYY]
Otherwise, both Transfer CFTs overwrite the information stored in the first of the two global sections. This leads to inconsistent operating conditions.
Usethe TCP/IP network To use the TCP/IP network, you must use the LOOPBACK option. From UCX 2.0 onwards, the default applied to this protocol is NOLOOPBACK.
Parameter settings To implement TCP/IP with Transfer CFT from UCX 2.0 and higher, submit the following command from a privileged account.
$ ucx set protocol TCP/loopback
Transfer CFT OpenVMS 3.3.2 Installation Guide 64 3 Post installation
Customization The CFT$TCPWINDSZ logical name enables you to define the socket send quota and the socket receive quota to be used during the creations of transfer sockets.
This option requires you to set a system UIC, SYSPRV, BYPASS, or OPER privilege. Too low of a value slows the transfer speed, and too large of a value results in CFTTPRO obstruction, which in turn reduces the transfer speed.
Using the programming interface Objects in the Transfer CFT programming interface (API) are implemented using a shareable library. This facility is used to prevent the applications that are calling the programming interface functions, from having to be re-linked each time that Transfer CFT is updated.
Implementation
1. To implement a shared library, the operator responsible for installing applications must install the CFTAPISH.EXE image and generate the application. 2. CFTAPISH.EXE must be installed as an image recognized by VMS. Available options are:
l The library is copied to the SYS$SHARE directory and the image is installed using a command, such as: $ install sys$share:cftapish.exe/share.
The application is linked by a link appli, appli.opt/opt type command, where appli designates the application object calling the Transfer CFT APIs and appli.opt is an option file containing the following lines:
PSECT_ATTR = CFTAUM, NOSHR sys$share:vaxcrtl.exe/share ! this option must not be ! used on an AXP ! system sys$share:cftapish.exe/share .
l The library is located in a Transfer CFT -specific directory.
If the directory is cft_exe:, the image is installed using a command such as install cft_ exe:cftapishr.exe/share. However, this image can later only be accessed using a logical name.
Example
$ define CFTAPISHR cft_exe:cftapish.exe
The application is linked by a link appli, appli.opt/opt type command, where appli designates the application object calling the Transfer CFT APIs and appli.opt is an option file containing the following lines:
Transfer CFT OpenVMS 3.3.2 Installation Guide 65 3 Post installation
PSECT_ATTR = CFTAUM, NOSHR sys$share:vaxcrtl.exe/share CFTAPISHR/share
By default, the VMSINSTAL procedure installs the shareable image in the CFT_EXE: directory for the Transfer CFT user group.
Transfer CFT logical names Transfer CFT uses a number of logical names to designate the resources or define an operating mode.
Default Transfer CFT directory Transfer CFT recognizes the following logical name, which must be defined so that Transfer CFT can locate images.
CFT_IMAGE This logical name points to a directory containing all Transfer CFT images. The CFTLOGIN.COM procedure supplied with the product defines it as CFT_EXE:, which must be defined with the /JOB attribute.
Other Transfer CFT directories The installation procedure creates a directory structure in which the supplied files are located. Each directory is defined by a logical name to make it easier to use. These logical names are not mandatory, but are used in the examples provided and the CFTLOGIN.COM procedure.
The following table lists the logical names that are defined in the standard Transfer CFT product, located in the D$CFT_RUN:[profile]CFTLOGIN.COM procedure.
Logical Description Name
D$CFT Logical name pointing to the Transfer CFT installation directory.
D$CFT_ Logical name pointing to the Transfer CFT HOME directory. INST
D$CFT_ Logical name pointing to the Transfer CFT RUNTIME directory. RUN
CFT_DAT Directory containing the Transfer CFT configuration definition files, catalog and communication file.
Transfer CFT OpenVMS 3.3.2 Installation Guide 66 3 Post installation
Logical Description Name
CFT_EXE Directory containing all the monitor images and the procedure used to link the Transfer CFT images.
CFT_LOG Directory containing the monitor log and accounting files.
CFT_PROC Directory containing the end of transfer procedure, and log and account switching samples.
CFT_RECV Directory used in the samples provided to receive the files transferred.
CFT_SCEN Directory containing Transfer CFT configuration samples.
CFT_SEND Directory used in the samples provided for the files sent.
CFT_UTL Directory containing the procedures used to define and modify the Transfer CFT environment.
CFT_PKI Directory containing certificate samples.
CFT_API Directory containing API samples.
CFT_EXIT Directory containing exit samples.
CFT_ACCNT Directory containing account files.
Standard Transfer CFT service files All Transfer CFT service files are designated by standard logical names known to Transfer CFT, or the associated utilities, and used by default.
The following table describes the logical names for Transfer CFT standard service files.
Standard Logical Meaning Name
CFTUCONF Client configuration file.
CFTUCONFDEF Transfer CFT dictionary values. Do not modify these values.
CFTPARM Transfer CFT configuration file. The CFTLOGIN.COM procedure supplied with the product defines it as CFT_DAT:CFTPARM.INX.
CFTPART Transfer CFT partner file. The CFTLOGIN.COM procedure supplied with the product defines it as CFT_DAT:CFTPART.INX.
Transfer CFT OpenVMS 3.3.2 Installation Guide 67 3 Post installation
Standard Logical Meaning Name
CFTCATA Transfer CFT catalog file. The CFTLOGIN.COM procedure supplied with the product defines it as CFT_DAT:CFTCATA.REL.
CFTCOM Transfer CFT communication file. The CFTLOGIN.COM procedure supplied with the product defines it as CFT_DAT:CFTCOM.REL. It must be defined with the /JOB attribute.
Additional Transfer CFT files By default, the following logical names are not known to Transfer CFT or utilities. They are declared explicitly in the configuration. However, they are used by the samples provided and the CFTLOGIN.COM procedure.
The following table lists the logical names that are used in the supplied Transfer CFT files.
Logical Name Meaning
CFTLOG Transfer CFT log files. CFTLOGA CFT_LOG:CFTLOG.LOG and CFT_LOG:CFTLOG.LOGA. These must be defined with the /JOB attribute.
CFTACCNT Transfer CFT accounting files. CFTACCNTA CFT_LOG:CFTACCNT.LOG and CFT_LOG:CFTACCNT.LOGA.
CFTPKU PKI base file. The CFTLOGIN.COM procedure supplied with the product defines it as CFT_PKI:CFTPKI.INX.
CFTEXAM VMS Share User API samples. The CFTLOGIN.COM procedure supplied with the product defines it as CFT_EXE:CFTEXAM.EXE.
Submitting Transfer CFT procedures A number of logical names are used to configure the Transfer CFT behavior with respect to the various procedures submitted by it. For more information, see theMONIT_MEM utility section.
The following table describes the logical names for the procedures that control Transfer CFT behavior.
Logical Name Description
CFT_QUEUE This logical name designates the name of the batch queue, in which the monitor submits the various procedures that it controls. It must be defined with the /JOB attribute.
Transfer CFT OpenVMS 3.3.2 Installation Guide 68 3 Post installation
Logical Name Description
CFT_SUBMIT This logical name defines the behavior of the monitor when it submits an end of transfer procedure. If the logical name is set to USER, the procedures are submitted from the transfer owner account.
CFT_PRINT This logical name is used to define a print queue, via which the procedure execution reports are printed. It must be defined with the /JOB attribute.
CFT_LOGDEL When set to YES, this logical name is used to request VMS to delete the execution reports of the procedures that it submits. Any other value maintains the reports in the SYS$LOGIN directory. It must be defined with the /JOB attribute.
Control memory usage Logical names are used to control Transfer CFT memory bottlenecks, refer to the Delivered components section. The following table describes the logical names that are used to control Transfer CFT memory.
Logical Name Meaning
CFT$MEMCSTE This logical name is used to define the amount of memory used by the monitor images in the Transfer CFT JOB. Its default value is 1 100 000.
CFT$CATA This logical name is used to define the percentage of available memory, as from which the monitor implements the bottleneck control mechanism. Its default value is 80.
CFT$COOL This logical name is used to define the percentage of available memory, as from which the monitor is no longer in the alert status triggered by CFT$CATA. Its default value is 70.
CFT$MEMDLAY This logical name is used to define a period after the monitor is no longer in the alert status, during which the monitor refuses any new incoming or outgoing connections, so that it can process the data already received.
CFT$MG_NB This logical name is used to define the number of 16-KB buffers reserved by Transfer CFT in the global section.
Transfer CFT OpenVMS 3.3.2 Installation Guide 69 3 Post installation
Concurrent access to the communication file If users belonging to a group other than the Transfer CFT group want to submit commands in the Transfer CFT communication file, you must enable the concurrent access control mechanism at system level. The CFT_LOCK logical name is used to implement this mechanism. For more information, see the Transfer CFT parameter settings on page 61 section.
CFT_LOCK If the CFT_LOCK logical name is set to SYSTEM, the concurrent access control mechanism is enabled at system level. Otherwise, the control is performed at group level. The SYSLCK privilege is required to implement the mechanism. The logical name must be defined with the /JOB attribute.
Optimize receive file write operations When receiving files, Transfer CFT allows you to optimize the way in which they are written, by performing disk accesses in virtual block mode instead of requesting that RMS write each record. The CFT$BLOCKIO logical name is used to implement this mechanism. The increased performance levels are particularly noticeable when writing files containing small-sized records.
CFT$BLOCKIO If this logical name is not defined or its substitution begins with the letter N, Transfer CFT writes the records received through RMS. In all other cases, the records are written in virtual block mode. The logical name must be defined with the /JOB attribute.
Transfer CFT privileges and identifiers Specific privileges must be granted to the Transfer CFT account, depending on the options selected during installation. Some privileges must also be assigned to users wishing to deposit requests in the communication medium.
The following table describes the Transfer CFT user types and privileges.
Name Type Meaning Privilege for Transfer CFT exclusively. Used to create the NETMBX Mandatory network mailboxes. Privilege for Transfer CFT exclusively. Used to implement OPER Optional the CFTLOG command NOTIFY parameter. Privilege for Transfer CFT exclusively. To be assigned if you SYSNAM Optional are using the DECnet network. Privilege for Transfer CFT exclusively. Used to create the TMPMBX Optional communication mailbox. Privilege for Transfer CFT exclusively. Used to implement BYPASS Optional the mechanism controlling user accesses to the files to be transferred.
Transfer CFT OpenVMS 3.3.2 Installation Guide 70 3 Post installation
Name Type Meaning Privilege for Transfer CFT exclusively. Used by the monitor CMKRNL Optional to submit the procedures from the transfer owner account. Privilege for Transfer CFT exclusively. Used to control concurrent accesses at system level when users from a SYSLCK Optional group other than the Transfer CFT group wish to deposit requests in the communication file. Privilege for Transfer CFT exclusively. To be assigned if you SHARE Optional are using Copilot. Identifier for the Transfer CFT exclusively. If this identifier is declared in SYSUAF, it must be assigned to the Transfer PSI$DECLNAME Optional CFT account, so that the account can be registered on the TCP-IP network to receive incoming calls. Identifier for the monitor. This identifier is used to obtain the Ethernet controller's hardware address, which is used NET$EXAMINE Mandatory when calculating the key. It can also be assigned to obtain this information via the ABOUT command.
Transfer CFT quotas During installation, the Transfer CFT account is allocated quotas, which are mandatory for its execution. These quotas are based on the replies that you give in the VMSINSTAL procedure.
Some of these quotas are assigned to each process in the JOB, and all processes in the JOB share others. For quotas assigned to each process, the account must be allocated the quotas required for the processes making the most intensive use of system resources. For the other quotas, you must estimate the resources used for all processes in the JOB.
According to your operating environment, you are advised to track monitor activities, so that you can fine-tune the quotas, as required.
Quotas Used by Transfer CFT.
Quota Level Use
ASTLM Process The ASTs are used for inter-process communications and network monitoring. The processes managing the network ( CFTTCPS) make the most intensive use of ASTs. For each process, there is one AST for inter-process communications, one AST per protocol using this type of network (TCP/IP) multiplied by the number of resources (CFTNET) in the same class, and two ASTs for each session in progress.
Transfer CFT OpenVMS 3.3.2 Installation Guide 71 3 Post installation
Quota Level Use
BIOLM Process Buffered I/Os are used for the file input/output operations and exchanges over the network. Each CFTTFIL process only performs one input/output at a given time. The processes managing the networks make the most intensive use of buffered I/Os. For each network process, there must be at least two buffered I/Os per active session.
BYTLM JOB This resource is associated with the buffered I/O. The use made of this resource is determined by the size of the disk write buffers and data exchanged over the network (CFTPROT command SRUSIZE and RRUSIZE parameters). It also depends on the number of active sessions. For the network buffers, you must include the protocol-level overhead, depending on the protocol used (session encapsulation).
DIOLM Process According to the VMS release, the file and network I/O system services are performed in direct or buffered I/O mode. Preference is given to buffered I/Os in the most recent releases of OpenVMS. This resource is therefore used less and less intensively.
ENQLM JOB Number of requests for locks managed by the DISTRIBUTED LOCK MANAGER at the same time. In particular, they are implemented by the RMS services. Transfer CFT uses two ENQs for each active process and two ENQs for each transfer in progress, in addition to one ENQ for the communication file access control mechanism.
JTQUOTA JOB Memory quota of the logical name table allocated for the JOB. The network mailbox names are in this table. However, this resource is used by the various logical names defined at JOB level.
PGFLQUOTA JOB Maximum number of pages that the JOB can use in the system page file. This quota determines the amount of dynamic memory that can be allocated by the JOB.
Transfer CFT OpenVMS 3.3.2 Installation Guide 72 3 Post installation
Quota Level Use
PRCLM Process Maximum number of sub-processes that can be created by a process. According to your configuration, specify the CFTTCOM, CFTLOG, and CFTTPRO processes and the various CFTTFIL processes for CFTMAIN, and a sub-process per type of network used TCP/IP for the CFTTPRO process.
TQELM JOB The timeouts are used for inter-process communications. Transfer CFT uses one for each active process.
Calculating the Transfer CFT quotas Depending on how you want to use Transfer CFT, the quotas required can vary.
Use these formulas to determine suitable values for the VMS-specific quotas to configure the Transfer CFT profile:
l prclm = 3 + maxtask + 8 (default = 19)
l tqelm = 8 + maxtask (default = 16)
l pgflquo = 180,000 + (10,000 * maxtask) (default = 500,000)
l jtquo = 7 168
Transfer CFT communications This section describes the communication modes between users and Transfer CFT.
Using CFTUTIL CFTUTIL, the command line interface for Transfer CFT, is able to translate Transfer CFT parameter setting commands and operating commands and can be activated in the following operational modes:
l Batch
l Command
l Interactive
Batch mode In batch mode, CFTUTIL executes the commands in a text file that are passed as a parameter. The file name must be preceded by either the # or @ character.
Example:
$ cftutil #cft_scen:cftdat.parm
Transfer CFT OpenVMS 3.3.2 Installation Guide 73 3 Post installation
Or:
$ cftutil @cft_scen:cftdat.parm
In this example, CFTUTIL executes the commands in the cft_scen:cftdat.parm file.
CFTU20I CFTU20I CFT/VMS CFTU20I Version 3.3.2 04/04/2018 CFTU20I (C) Copyright AXWAY 1989-2018 CFTU20I ====> Starting Session on 04/04/2018 Time is 17:03:35 CFTU20I CFTU00I CFTFILE _ Correct (TYPE=PARAM,FNAME=CFTPARM) CFTU00I CFTFILE _ Correct (TYPE=PART,FNAME=CFTPART) CFTU00I CFTFILE _ Correct (TYPE=CAT,FNAME=CFTCATA,RECNB=600) CFTU00I CFTFILE _ Correct (TYPE=COM,FNAME=CFTCOM,RECNB=50) CFTU00I CFTFILE _ Correct (TYPE=LOG,FNAME=CFTLOG) CFTU00I CFTFILE _ Correct (TYPE=LOG,FNAME=CFTLOGA) CFTU00I CFTFILE _ Correct (TYPE=ACCNT,FNAME=CFTACCNT) CFTU00I CFTFILE _ Correct (TYPE=ACCNT,FNAME=CFTACCNTA) CFTU00I RETURN _ Correct (CODE=0) CFTU20I Number of Command(s) 8 CFTU20I Number of error(s) 0 CFTU20I Ending Session on 23/04/2018 Time is 17:03:45 CFTU20I Session active for 0:00:10 $
Interactive mode In Interactive mode, control is passed to the CFTUTIL utility, and the CFTUTIL> prompts you to enter a command:
Enter a CFT command $ cftutil CFTU20I CFTU20I CFT/VMS CFTU20I Version 3.2.1 08/08/2015 CFTU20I (C) Copyright AXWAY 1989-2015 CFTU20I ====> Starting Session on 23/10/2015 Time is 17:08:03 CFTU20I
To exit CFTUTIL, press Ctrl+Z or enter /end.
Transfer CFT OpenVMS 3.3.2 Installation Guide 74 3 Post installation
File-based communication File-based communication is the default communication mode. In the configuration file CFTCOM card, you must set the TYPE parameter to FILE and the FNAME parameter to CFTCOM for example. For more information, refer to the Transfer CFT 3.0.1 User's Guide or online help.
By default, CFTUTIL dialogs with Transfer CFT using the CFTCOM communication file. There are two ways to change the communication file:
l CFTUTIL CONFIG command
l CFTCOM logical name
CFTUTIL CONFIG command Prior to submitting a command to Transfer CFT, you must change the default setting using the CONFIG command, by specifying the new file that you want to use for communication purposes.
$ cftutil CFTU20I CFTU20I CFT/VMS CFTU20I Version 3.0.1 15/02/2012 CFTU20I (C) Copyright AXWAY 1989-2012 CFTU20I ====> Starting Session on 06/07/2012 Time is 14:58:27 CFTU20I 1:[CFU] config type=com,mediacom=file,fname=my_file CFTU00I CONFIG _ Correct (type=com,mediacom=file,fname=my_file) 2:[CFU]
l If you perform this operation, the configuration is lost when you exit the CFTUTIL utility. You must redo this operation each time that you use CFTUTIL.
l You cannot implement communications using another file in line command mode using this method.
l In batch mode, you must specify this command on the first line of the file so that subsequent commands are deposited in the new communication medium.
CFTCOM logical name Another way to change the communication file is to redefine the CFTCOM logical name so that it points to the required file, prior to using CFTUTIL. This is the preferred procedure. As long as the CFTCOM logical name points to the new file, CFTUTIL automatically uses it as the communication file.
$ define CFTCOM my_file $ CFTUTIL
Transfer CFT OpenVMS 3.3.2 Installation Guide 75 3 Post installation
CFTU20I CFTU20I CFT/VMS CFTU20I Version 3.0.1 15/02/2012 CFTU20I (C) Copyright AXWAY 1989-2012 CFTU20I ====> Starting Session on 06/07/2012 Time is 15:01:04 CFTU20I 1:[CFU]
COPILOT You can use Copilot to configure the communication file by declaring the new communication media file in the relevant field of the Administration Files management tab in the Transfer CFT's Ongoing Configuration.
API Your application can configure a new file name prior to submitting a command. For more information, refer to the Transfer CFT 3.0.1 User's Guide or online help.
In C for example:
rc = cftau("COM","F=my_file");
Access rights Communication file users must have read and write access rights for the file. If users belong to:
l The same group, file protection must be: S:RWED,O:RWED,G:RWE,W:
l Different groups, file protection must be: S:RWED,O:RWED,G:RWE,W:RWE
You can also grant write access rights to authorized users only using ACLs on the file.
If users from various groups use the communication file, it is recommended that you set the CFT_ LOCK logical name to SYSTEM and grant the SYSLCK privilege to the relevant users. For more information, see the Transfer CFT parameter settings section.
Mailbox communication You must first make the temporary mailbox name table available all users that are likely to communicate with Transfer CFT. Enter:
$ define/tab=lnm$process_directory lnm$temporary_mailbox XXX
Transfer CFT OpenVMS 3.3.2 Installation Guide 76 3 Post installation
Where XXX is a logical name table, such as LNM$SYSTEM or other global logical name table, that can be accessed by all users communicating with Transfer CFT. The account running the Transfer CFT image must have write access rights for this table.
Then configure Transfer CFT so that it can communicate by mailbox. In the configuration file CFTCOM card, you set the TYPE parameter to MBX and the NAME parameter to CFTMBX for example. For more information refer to the Transfer CFT online documentation.
CFTUTIL By default, CFTUTIL dialogs with Transfer CFT via the CFTCOM communication file. Therefore prior to submitting a command to Transfer CFT, change this default setting using the CONFIG command and specify the MAILBOX used for communication purposes:
$ cftutil CFT/VMS CFTU20I Release 3.0.1 21/03/2012 CFTU20I (C) Copyright SOPRA 1993-2012
CFTUTIL>config type=com,mediacom=mbx,fname=cftmbx CFTU00I CONFIG COMM _ Correct CFTUTIL>
Note The configuration is lost when you exit the CFTUTIL utility. You must repeat this operation each time that you use CFTUTIL.
You cannot implement communications through the mailbox feature with CFTUTIL in command line mode.
In batch mode, specify this command on the first line of the file so that subsequent commands are deposited in the MAILBOX.
Copilot When using Copilot, configure communications through the mailbox by defining the relevant field of the Administration Transfer CFT Files management tab.
API Your application must configure the mailbox communication mode prior to submitting a command. For more information on APIs, refer to the Programming sub-book in the Transfer CFT online documentation.
In C for example:
rc = cftau("COM","M=cftmbx");
Transfer CFT OpenVMS 3.3.2 Installation Guide 77 3 Post installation
Build APIs and exits
Using the programming interface Objects in the Transfer CFT programming interface, API, are implemented using a shareable library. This facility is used to prevent the applications that are calling the programming interface functions from having to be re-linked each time Transfer CFT is updated.
Implementation
1. To implement a shared library, the operator responsible for installing applications must install the CFTAPISH.EXE image and generate the application. 2. CFTAPISH.EXE must be installed as an image recognized by VMS. Available options are:
l The library is copied to the SYS$SHARE directory and the image is installed using a command, such as: $ install sys$share:cftapish.exe/share. The application is linked by a link appli, appli.opt/opt type command, where appli designates the application object calling the Transfer CFT VMS APIs and appli.opt is an option file containing the following lines:
PSECT_ATTR = CFTAUM, NOSHR sys$share:vaxcrtl.exe/share ! this option must not be ! used on an AXP ! system sys$share:cftapish.exe/share.
l The library is located in a Transfer CFT VMS-specific directory.
If the directory is cft_exe:, the image is installed using a command such as install cft_ exe:cftapishr.exe/share. However, this image can later only be accessed using a logical name.
Example: $ define CFTAPISHR cft_exe:cftapish.exe
The application is linked by a link appli, appli.opt/opt type command, where appli designates the application object calling the Transfer CFT VMS APIs and appli.opt is an option file containing the following lines:
PSECT_ATTR = CFTAUM, NOSHR sys$share:vaxcrtl.exe/share CFTAPISHR/share
By default, the VMSINSTAL procedure installs the shareable image in the CFT_EXE: directory for the Transfer CFT user group.
Transfer CFT OpenVMS 3.3.2 Installation Guide 78 3 Post installation
Using EXIT functions You can implement EXIT functions in Transfer CFT. For more information on EXIT functions, refer to the sub-book Exits in the Transfer CFT online documentation.
ASIT EXIT Once the EXIT function has been developed and tested, you must link it with the CFTMAIN.EXE image so that it is taken into account.
If the EXIT function that you want to use is in the EXIT.C source file, for example, perform the following operations:
$ cc exit $ link exit,XMKT_BDIR:[opt]cftmain.opt/opt/exe=cft_exe:cftmain.exe
EXIT functions Transfer CFT can be used to develop advanced EXIT functions. For more information on EXIT functions, refer to the Transfer CFT online documentation. Additionally, you can refer to the CFT_ EXIT: directory contents.
Using the programming interface You can develop an application that can communicate directly with Transfer CFT using the programming interface, which is supplied in the standard Transfer CFT package. For more information, refer to the Transfer CFT online documentation.
After you develop the application, you must generate its image, including the objects enabling communications with Transfer CFTT, using the shareable library supplied with the product.
Implementing object libraries To link your application image, use an option file. For more information, refer to the Programming Utilities LINKER manual.
Add the following lines to the option file after declaring your objects:
PSECT_ATTR=GLOBZONE,PIC,OVR,REL,GBL,SHR,NOEXE,WRT,PAGE CLUSTER=GLOBMEM COLLECT=GLOBMEM,GLOBZONE cft_exe:CFTAPISH.EXE/share SYS$LIBRARY:VAXCRTL/lib
Transfer CFT OpenVMS 3.3.2 Installation Guide 79 3 Post installation
If your application comprises the myobject1.obj and myobject2.obj objects for example, your option file has the following format:
PSECT_ATTR=GLOBZONE,PIC,OVR,REL,GBL,SHR,NOEXE,WRT,PAGE CLUSTER=GLOBMEM COLLECT=GLOBMEM,GLOBZONE myobject1.obj myobject2.obj cft_exe:CFTAPISH.EXE/share SYS$LIBRARY:VAXCRTL/lib
Sentinel Universal Agent
Configure Transfer CFT To restrict tracking to important transfers only, use the XFB.Transfer Tracked Object activation parameters in the transfer commands (SEND and RECV), in the partner definitions (CFTPART) and in the Transfer CFT files (CFTSEND and CFTRECV).
An activation parameter can have the following values:
l NO: no tracking
l ALL: complete tracking is tracking for each change in transfer status
l SUMMARY: summary tracking is tracking for creation and end of transfer processes
l UNDEFINED: undefined value
Pre- and post-processing tracking A file transfer only represents one of the actions involved in the processing chain. In terms of tracking, Transfer CFT provides the means of linking this action to the actions that take place both before and after processing.
Pre-processing tracking Transfer CFT provides two parameters in a transfer deposit command. An application that is tracking its activity can use these parameters to supply:
l Tracked Instance identifier (application Tracked Instances CycleId) with a maximum length of 250 characters
l Tracked Object name, with a maximum length of 50 characters
An application can use the Sentinel TRKUTIL or API UA components to notify its own tracked events.
APPCYCID and APPOBJID parameters of the SEND/RECV commands
Transfer CFT OpenVMS 3.3.2 Installation Guide 80 3 Post installation
l APPCYCID: CycleId of the application Tracked Instances
l APPOBJID: name of the application Tracked Object
Post-transfer processing The Transfer CFT end-of-transfer procedures offer two symbolic variables &XFRCYCID, &XFROBJID for all EXECxx procedures:
l &XFRCYCID: CycleId of transfer Tracked Instances
l &XFROBJID: name of the XFB.Transfer Tracked Object
Fields XferCycleId[32+1] and XferObjetcId[32+1] in the exit structures:
l End-of-transfer exit
l File exit (phase before allocation)
l Directory exit (requester mode only)
Troubleshooting the Sentinel server or Event router In the event of a communication problem with the Sentinel Server or Event Router, the CFTS31W message is displayed in the Transfer CFT LOG, and the trace message is stocked in the buffer file of the Sentinel tracking task.
When you restart Transfer CFT, the application tries to re-send all records in the buffer file. This operation can be time consuming because it depends on the number of messages in the file. As a precaution, you should use the TRKUTIL utility to empty the buffer file before restarting Transfer CFT.
Example TRKUTIL utility use
trkutil Sendfile
Using the Sentinel Universal Agent For Transfer CFT, the Sentinel component is called a Universal Agent. This Sentinel component is an independent process. It transports messages using a TCP/IP network.
For information on implementing Sentinel tracking, please refer to the Transfer CFT 3.0.1 User's Guide available at https://support.axway.com.
Transfer CFT OpenVMS 3.3.2 Installation Guide 81 3 Post installation
Multi-node architecture
Working in a multi-node environment This section describes how to enable multi-node functioning in your Transfer CFT environment.
1. Use the unified configuration parameter to enable the multi-node feature. To enable, set value to yes.
CFTUTIL uconfset id=cft.multi_node.enable,value=yes
2. To add a host, enter the command:
$CFT add_host -hostname
3. Activate the Transfer CFT node that you will use.
$CFT enable_node -n
4. Start the node that you activated above in Step 3.
$CFT start -n
5. To start the Transfer CFT Copilot server, enter:
$COPSTART
6. You can use the CFT.COM script to manage your Transfer CFT environment, as described in the following table.
Command Actions start Start all nodes. start -n
restart Restart all nodes. restart -n
Example
Transfer CFT OpenVMS 3.3.2 Installation Guide 82 3 Post installation
For the following example host: $ CFT add_host -hostname ia64 -host 127.0.0.1 To activate and start a node pass the commands: $CFT enable_node -n 0 $CFT start_node -n 0 To add ONE node, use the command: $CFT add_node To disable and stop a node use the commands: $CFT stop_node -n 0 $CFT disable _node -n 0 After stopping all nodes, you can stop COPILOT. Enter: $COPSTOP
About multi-node architecture This topic describes the Transfer CFT multi-node feature, which provides you with horizontal scalability and high availability for fail overs. See also Active/active1 for conceptual information.
Multi-node benefits include:
l Horizontal scalability: increased transfer flow capacity
l High availability: active/active including patch management on an active cluster, and automatic node restart after fail over
l Traffic management: balancing load between nodes through an external load balancer or DNS
Note Transfer CFT supports the following OS for muti-node architecture: Windows-x86, Linux- x86, AIX-power, HPUX-parisc, HPUX-ia64, Sun-SPARC, Sun-x86.
Prerequisites Transfer CFT in multi-node architecture requires:
l One key per node must have the cluster option, and if there is more than one host you require at least one valid key per host
l A shared file system for use of a multi-node architecture on several hosts. Additionally, the system must be configured prior to the multi-node installation and the shared disk ready when starting the Copilot server.
1You configure two or more Transfer CFTs, up to four nodes, each having an independent workload. These nodes will then run as indi- vidual nodes until a fail over occurs. When a fail over occurs, one of the other nodes takes over from the failed node. This secondary node offers services to new and existing transfer requests and tasks, until the original node resumes activity. When the failed node restarts, a manual intervention required in Transfer CFT, it resumes its connections from the secondary or replacement node. To sum- marize, when a fail over occurs the external Transfer CFT is oblivious to any change. The requests are directed to the load balancer, which resubmits any uncommitted transactions to the replacement node. During fail back, the connection returns to the original node.
Transfer CFT OpenVMS 3.3.2 Installation Guide 83 3 Post installation
Architecture The Transfer CFT multi-node architecture is based on hosts, nodes, and a shared file system.
Regardless of the number of servers hosting the nodes from outside the cluster, the nodes are viewed as a single machine on an internal network.
What is a host?
A host refers to a physical or virtual server located behind a load balancer, or other DNS mechanism. A server can host zero or multiple nodes. Transfer CFT itself does not manage the round robin or other load balancing mechanism.
What is a node?
A node is a Transfer CFT runtime running on a host. Multiple nodes are called a Transfer CFT cluster, which can run on one or multiple hosts.
What is a shared file system?
A shared file system is a file system resource that is shared by several hosts.
General architectural overview
l Transfer CFT provides a node manager per host that monitors every node and checks that its nodes are active. If a node goes down, the node manager detects the inactivity and takes over that node's activity.
l In addition to the node manager Transfer CFT provides a connection dispatcher that listens on the Transfer CFT server port, and monitors incoming traffic.
l For multiple nodes to be able to access the same files, using the same set configuration, the system requires the use of a shared file system. The shared disk provides communication, configuration, partners, data flows, internal datafiles and nodes.
l Incoming flow passes by a load balancer. Note that the exiting flow does not pass through an external load balancer.
Architectural component details
Copilot Copilot operates three services: the node manager, the connection dispatcher, the UI server. Only one Copilot runs per host.
Node manager
The node manager monitors all nodes that are part of the Transfer CFT multi-node environment (independent of the host). The monitoring mechanism is based on locks provided by the file system lock manager.
Transfer CFT OpenVMS 3.3.2 Installation Guide 84 3 Post installation
When a node is not running correctly, the node manager tries to start it locally.
Connection dispatcher
The connection dispatcher checks for inbound connections, and dispatches requests to each node.
On startup, the Transfer CFT nodes connect to the connection dispatcher service and register their TCP interface/port pairs. The service listens to these access points and passes incoming connections to the various Transfer CFT nodes.
The connection dispatcher service allows running multiple nodes, which listen at the same access points (interface/port pairs) on the same host.
You can set the dispatcher to use either a round-robin load balancing, or define a one-to-one relationship between a partner and a node. A one-to-one relationship ensures that for any given partner the transfers are kept in the correct chronological order.
Run-time files All runtime data are stored on a shared file system.
The following internal datafiles are shared between nodes:
l Parameter internal datafile (CFTPARM)
l Partners internal datafile (CFTPART)
l PKI base (CFTPKU)
l Main communication media file (CFTCOM)
l Unified Configuration (UCONF)
The following internal datafiles are node specific, and the filename is flagged by the node identifier:
l Catalog (cftcata00, cftcata01,...) located in
l Communication media file (cftcom00, cftcom01,...) located in
l Log files (cftlog00, cftlog01,...) located in
l Output file (cft00.out, cft01.out,...) located in
l Account file (cftaccnt00, cftaccnt01,...) located in
Node recovery overview There are two possibilities when a node manager detects a node failure:
l If it is a local node fail over, the node manager automatically attempts to restart the node on the local server.
l If it is a remote node fail over, the node manager waits for the remote node manager to restart the node. If the remote node manager does not restart the node before the timeout, the local node manager will restart the node on the local server.
Transfer CFT OpenVMS 3.3.2 Installation Guide 85 3 Post installation
After the node is restarted, whether local or remote, it will complete all transfer requests that were active when the failure occurred.
After a fail over, manual intervention is required to rebalance the cluster.
When a node manager fails but nodes are still active, after a timeout nodes are stopped and restarted on another server. A manual intervention is required to restore the node manager.
Transfer recovery overview When a node receives an incoming request - a transfer receive, restart, acknowledgement or negative acknowledgement - if the corresponding transfer record cannot be found in the node's own catalog, the node requests the transfer record from other nodes through the CFTPRX task.
Possible scenarios include:
l If another node has the catalog record, the node retrieves it and perform the transfer.
l If no nodes have the record, an error is returned.
l If any one of the nodes does not respond, the requesting node continues to retry all nodes until the session's timeout. Once the timeout is reached, the node ends the connection. After this, the remote partner retries the request according to its retry parameters.
In the case of node failure during the transfer recovery process, the catalog record is locked in both catalogs until both nodes are available for recovery.
Limitations and restrictions The synchronous communication media is not available in multi-node environment. If a synchronous communication media is enabled when the multi-node architecture is enabled, the Transfer CFT will not be able to start. Additionally note the following restrictions:
l Transfer acceleration is not available in server mode.
l Bandwidth control is calculated by node.
l Accounting statistics are generated by node.
l Nodes are not automatically re-balanced when a host is recovered after a failure.
l Duplicate file detection is not supported.
Multi-node commands This topic describes how to mange Transfer CFT nodes, and related actions such as restarting a stopped node, or rebalancing after a fail over.
cftinit The cftinit command initializes Transfer CFT internal datafiles. If nothing is specified, then all internal datafiles are initialized, both common and specific.
Transfer CFT OpenVMS 3.3.2 Installation Guide 86 3 Post installation
Syntax cftinit [options]
Options
-c|-common only common internal datafiles are initialized (PARM, PART, main COM)
-n|-node only node specific internal datafiles are initialized (CATALOG, COM, LOG)
Usage cftinit conf/cft-tcp.conf con/cft-tcp-part.conf
All internal datafiles are initialized using provided configuration files.
cftinit –c conf/cft-tcp.conf con/cft-tcp-part.conf
Common internal datafiles are initialized using provided configuration files.
cftinit –n 2
Specific internal datafiles for node 2 are initialized (cftcata02, cftcom02, cftlog02).
copsmng The copsmng command starts the Copilot (Node Manager, Connection Dispatcher, UI server)
Syntax copsmng
Usage copsmng
copstop The copstop command stops the Copilot (Node Manager, Connection Dispatcher, UI server). When stopping a Copilot on a host, all nodes running on this host are stopped and re-started on the other hosts in the cluster.
Syntax copstop
Transfer CFT OpenVMS 3.3.2 Installation Guide 87 3 Post installation
Usage copstop
cft start The cft start command starts one or all nodes. If no node is specified, all nodes are started.
Note Node managers must be started first.
Syntax cft start [options]
Options
The -n|-node
Usage cft start
All nodes are started by the node managers.
cft start –n 0
Node 0 is started by a node manager.
cft stop The cft stop command stops one or all nodes. If no node is specified, all nodes are stopped.
Syntax cft stop [options]
Options
The -n|-node
Usage cft stop
Stops all nodes.
cft stop –n 0
Transfer CFT OpenVMS 3.3.2 Installation Guide 88 3 Post installation
Stops node 0.
cft restart The cft restart command re-stars one or all nodes. If no node is specified all nodes are re-started.
Note Node managers must be started first.
Syntax cft restart [options]
Options
The -n|-node
The -ln|-local_node re-starts all nodes hosted locally that are running on the host from where the command is performed.
Usage cft restart
All nodes are re-started by the node managers.
cft restart –n 0
Node 0 is re-started by a node manager.
cft restart –ln
All nodes hosted locally are re-started by the node manager.
cft add_host The cft add_host command adds a new host entry in the configuration. The following UCONF parameters are set:
l uconf:cft.multi_node.hostnames
l uconf:cft.multi_node.hostnames.
Syntax cft add_host –hostname
Usage cft add_host –hostname srv0 –host srv0.domain.int
Transfer CFT OpenVMS 3.3.2 Installation Guide 89 3 Post installation
cft add_node The cft add_node command adds a new node to the Transfer CFT cluster. The number of nodes is incremented (uconf: cft.multi_node.nodes = N+1) . The internal datafiles associated with the new node are initialized and the node state is set to DISABLED (uconf:cft.multi_node.nodes.
Syntax cft add_node
Usage cft add_node
cft remove_node The cft remove_node command removes the node identified by the higher node id in the Transfer CFT cluster. To remove a node, the node state must be both DISABLED (uconf:cft.multi_ node.nodes.
The node number is decremented (uconf: cft.multi_node.nodes = N+1) , and any internal datafiles associated with the node are removed.
Syntax cft remove_node –n
Usage cft remove_node –n 3
cft enable_node The cft enable_node command enables the specified node. The node state is set from DISABLED to ENABLED_STOPPED (uconf:cft.multi_node.nodes.
Syntax cft enable_node -n -
Usage cft enable_node -n -
Transfer CFT OpenVMS 3.3.2 Installation Guide 90 3 Post installation
cft disable_node The cft disable_node command disables the specified node. The parameter uconf:cft.multi_ node.nodes.
l The node unregisters its listening points from the connection dispatcher so that it does not received incoming requests.
l Outgoing requests coming from APIs are no longer dispatched to this node.
l Once the catalog related to the node is empty, the node state is set to DISABLED and the node stops.
Syntax cft disable_node -n -
Usage cft disable_node -n -
cftping The cftping command checks the status of one or all enabled nodes. By default the cftping checks status of all nodes.
Return values:
l 0: all enabled nodes are stopped
l 1: all enabled nodes are running
l 2: not all enabled nodes are running
Syntax cftping [options]
Options
-n|-node
-v verbose mode
-p shows PID (Process IDs) of all CFTMAIN processes
-h shows the help
Transfer CFT OpenVMS 3.3.2 Installation Guide 91 3 Post installation
Listlog Use the CFTUTIL listlog command to display the log content, which can be defined according to certain criteria, such as date or node. Additionally, you can filter the log according to multiple criteria, or view a log that is merged for several nodes in cluster mode.
Cftutil listlog LINES=-200, cftutil listlog node=2
Display/Listcat Use the CFTUTIL display or CFTUTIL listcat to show catalog transfer records. In multi-node, these commands aggregate all catalog internal datafiles to show catalog transfer records as a unique catalog.
Note The first character in the IDTU corresponds to the node number.
Listnode The CFTUTIL listnode displays the status of the Transfer CFT cluster, including information about hosts and nodes that are part of the Transfer CFT multi-node architecture.
Example
In this example four nodes are running on four different hosts.
Transfer CFT OpenVMS 3.3.2 Installation Guide 92 3 Post installation
Managing multi-node This topic describes how to set up and manage your multi-node environment. It describes:
Starting the Transfer CFT cluster
Start all node managers For each host perform the command: copsmng
Start all nodes On one of the hosts in the cluster, perform the command: cft start
Stopping the Transfer CFT cluster
Stop all nodes On one of the hosts in the cluster, perform the command: cft stop
Stop all node managers For each host, perform the command: copstop
Add a host to the Transfer CFT cluster
Install Transfer CFT binaries on the target host
l If binaries and runtime files are stored on the shared disk, skip this step and go to Add the target host to the cluster on page 93.
l Install binaries on the host using the Axway Installer and choose the Cluster Installation Architecture with the additional nodes option.
Add the target host to the cluster Execute the command: cft add_host –hostname
Start the node manager Start the node manager using command: copsmng
Transfer CFT OpenVMS 3.3.2 Installation Guide 93 3 Post installation
Add a node to the Transfer CFT cluster In this example the Transfer CFT cluster accounts at the beginning two nodes, node 0 and node 1.
Add a node Execute the following command to add a new node: cft add_node
The node 2 is created. The cluster is composed of three nodes: node 0, node 1 and node 2. All associated files associated with node 2 are initialized and its node state is set to DISABLED.
Note When adding a node, you must add the corresponding new license key for that node in the license-key file
Enable a node Once the new node has been added, you can now enable it using the command: cft enable_node -n 2
Start a node The node 2 can be started using the command: cft start -n 2
Removing a node from the Transfer CFT cluster Note Only the last node can be removed.
Disable the last node The last node must be fenced before removing a node. To fence a node before removing it, enter: cft disable_node –n
The node runs as long as its catalog is not empty. Once the catalog is empty, the node state is set to DISABLED and the node stops automatically.
Remove the last node After fencing and stopping the last node, you can remove it. Enter: cft remove_node –n
Rebalancing after a fail over Once the failed node manager is running again, you can rebalance the cluster by re-starting one or multiple nodes.
In this example there are two hosts (host00 and host01), and two nodes (node00 and node01). Node00 is running on host00, and node01 is running on host01.
Transfer CFT OpenVMS 3.3.2 Installation Guide 94 3 Post installation
1. Host00 and node00 experience a fail over. 2. The host01 node manager re-starts the node00 locally. 3. Node00 and node01 run on host01. 4. Host00 and its node manager are manually re-started. 5. From one of the Transfer CFT cluster hosts, host00 or host01, execute the command: cft restart –n 0 6. The host00 node manager restarts the node00 locally.
Step results: Node00 is running on host00, and node01 running on host01.
Multi-node unified configuration parameter This topic presents the multi-node uconf parameters and their default values. The column Modify indicates a strong recommendation that you should not modify this value if No is indicated.
Parameters Descrip Defau Val Modi tion lt ues fy value
cft.multi_node.enable Enable/disable No Yes, No Yes the multi-node feature
cft.multi_node.max Maximum 16 integer from No number of nodes 0 to 16
cft.multi_ Lock file for the $(cft.runtime_ fname Yes node.cftcomlock.fname main dir)/data/cftco communication m.lck media file task in multi-node
Transfer CFT OpenVMS 3.3.2 Installation Guide 95 3 Post installation
Parameters Descrip Defau Val Modi tion lt ues fy value
cft.multi_ Specify the round_robin round_ Yes node.cftcom.dispatcher_ dispatching robin, node_ policy policy affinity -round_robin: Random dispatching across all nodes occurs. -node_affinity: Creates a one to one link between a partner and a node. Transfer requests for a given partner will always be performed by the same node.
cft.multi_ Shared file for $(cft.runtime_ fname Yes node.sharedidt.fname global IDT dir)/data/cftsidt calculation in multi-node
cft.multi_ Use global IDT No Yes, No Yes node.sharedidt.enable calculation method
cft.multi_ Used to select unknown unknown, Yes node.shared.filesystem.type appropriate posix, nfs, consistency cifs enforcement strategy. If Transfer CFT is using NFSv4, you must enter the value nfs in lower case.
Transfer CFT OpenVMS 3.3.2 Installation Guide 96 3 Post installation
Parameters Descrip Defau Val Modi tion lt ues fy value
cft.multi_node.transfer_ Timeout in 30 integer Yes recovery_timeout seconds for transfer recovery process (seconds)
cft.multi_node.transfer_ Delay in seconds 20 integer Yes recovery_retry_delay for transfer recovery retry (seconds)
cft.multi_node.connection_ Delay in seconds 10 integer Yes retry_delay for connection retry between nodes (seconds)
cft.multi_node.hostnames List of hosts list No which handle the multi-node architecture
cft.multi_ Address (FQDN or string Yes node.hostnames.
cft.multi_ Process ID of No node.hostnames.
cft.multi_ Copilot STOPPED INITIALIZIN No node.hostnames.
cft.multi_ Process ID of UI No node.hostnames.
Transfer CFT OpenVMS 3.3.2 Installation Guide 97 3 Post installation
Parameters Descrip Defau Val Modi tion lt ues fy value
cft.multi_ Windows socket integer No node.hostnames.
cft.multi_ Notification port integer No node.hostnames.
cft.multi_node.nodes Number of nodes 2 integer from No 2 to $(cft.multi_ node.max)
cft.multi_node.nodes.
cft.multi_node.nodes.
cft.multi_node.nodes.
cft.multi_node.nodes.
cft.multi_node.nodes.
cft.multi_node.nodes.
Transfer CFT OpenVMS 3.3.2 Installation Guide 98 3 Post installation
Parameters Descrip Defau Val Modi tion lt ues fy value
cft.multi_node.nodes.
Connection dispatcher parameters
Parameter Descripti Default Valu Modif s on value es y
copilot.connection_ Enable client Yes (multi-node), Yes, No Yes dispatcher.enable registering No otherwise connection dispatching
copilot.connection_ Connection integer Yes dispatcher.control.p dispatcher TCP ort control port
copilot.connection_ Client Registering to 5 integer Yes dispatcher.retry_ connection delay dispatcher retry delay in seconds
copilot.connection_ Client Registering to 300 integer Yes dispatcher.retry_ connection timeout dispatcher timeout in seconds
copilot.connection_ Unix Socket path $(cft.runtime_ fname Yes dispatcher.unix.af_ name for dir)/run/S_ unix_fname connection $(cft.short_ dispatching hostname)DISPAT CH
copilot.connection_ Local TCP port for 1800 integer Yes dispatcher.nt.local_ connection port dispatching
Transfer CFT OpenVMS 3.3.2 Installation Guide 99 3 Post installation
Node manager parameters
Parameter Descriptio Defaul Value Modif s n t s y value
copilot.node_ Interval between 10 integer Yes manager.watchperio checking the status d of two Transfer CFT nodes
Transport security
Security elements This section describes how to implement transfer security with Transfer CFT 3.3.2 and higher.
Delivered components To implement the transfer security measures using SSL protocol, you must have access to certificates. Standard certificates are supplied as sequential files that are restored during the product installation.
The following table describes the certificates.
Certificate name Function
AXWAY_MFT_DEMONSTRATION_ROOT_ Local authority certificate. CERTIFICAT.DER
MFT_DEMONSTRATION_USER_CERTIFICATE.DER Client certificate signed by the local authority.
MFT_DEMONSTRATION_USER_CERTIFICATEK.DER Private key associated with the preceding certificate.
CFTPKI.INX Indexed certificate internal datafile that is generated by PKIUTIL.
PASSPORTCA.PEM Certificate used for PassPort PS.
Transfer CFT OpenVMS 3.3.2 Installation Guide 100 3 Post installation
Certificate name Function
MFT_DEMONSTRATION_USER_CERTIFICATE.P12 Certificate in pkcs12 format.
Logical names and symbols The following table lists the logical name and the role of the logical name.
Logical name Role
CFTPKU Logical name specifying the certificate database
.PKIUTIL is the symbol that launches PKIUTIL.EXE program execution.
Modifying parameters You must define specific elements in setting the product parameters in order to implement the transfer security measures as described in the Transfer CFT Transport Security sub-book in the Transfer CFT online documentation.
For the CFTPARM card, you must define the number of CFTTSSL tasks to use (sslmtask) and the location of the configuration file (CFTPKU).
cftparmid = IDPARM0, . . . sslmtask = 1, pkifname = CFTPKU, pkipassw = ‘XXX’, . . .
For the CFTPROT card, you must define a new protocol that uses the CFTSSL type card.
cftprot id = PANYRT, type = PESIT, . . . ssl = SSLPESIT
The addition of two CFTSSL-type cards, associated with this protocol, define a server mode (direct = server) and a client mode (direct = client). These cards are designed to work according to version 3 of the SSL protocol.
Server configuration
cftssl id = SSLPESIT,
Transfer CFT OpenVMS 3.3.2 Installation Guide 101 3 Post installation
direct = SERVER, rootcid = (AXWMFTCA), usercid = AXWMFTUSER, passw = 'AXWMFTUSER', ciphlist = (61,60,59,53,47,10,9,5,4,1,2), verify = NONE, parm = 'SERVER ONLY AUTH'
Client configuration
cftssl id = SSL_LOOP0, direct = CLIENT, rootcid = (AXWMFTCA), passw = 'AXWMFTCA', ciphlist = (53,47,10,9,5,4,1,2), verify = REQUIRED, parm = 'SERVER ONLY AUTH', mode = replace
Create a LOOPAT partner that dialogs in TCP and uses a new protocol to secure its exchanges (ssl = PANYRT):
cftpart id = LOOPSSL0, prot = PESITSSL, sap = %uconf:samples.pesitssl_sap.value%, nspart = LOOPSSL0, nrpart = LOOPSSL0, ssl = SSL_LOOP0, mode = replace cfttcp id = LOOPSSL0, host = XXXXXXXX, cnxout = 8, cnxin = 8, cnxinout = 8, mode = replace
Upload certificates This procedure describes how to import certificates (PEM, DER, P12, KEY) to your OpenVMS system.
1. Use FTP to upload your certificates to the OpenVMS system in binary mode. 2. Set the attributes associated with certificates and keys using the command in the following example:
Transfer CFT OpenVMS 3.3.2 Installation Guide 102 3 Post installation
SET FILE/ATTRIB=(LRL:4096,RFM:UDF) ROOT.der
3. Once you have converted all of the certificates and keys, you can create your PKI database as described in the next section, Creating an internal datafile for certificates.
Creating an internal datafile for certificates An indexed file, CFTPKI.INX certificate database, is included in the product delivery.
To create another database, you must activate the PKIFILE.EXE program with the following command, which can create the envelope of the indexed file containing the certificates:
PKIFILEMODE=CREATE, FNAME= '&PKIVOL:&PKIDVC:&PKIFIC'
Generating the certificate internal datafile You can generate the certificate internal datafile from the delivered *.DER files. This utility interprets a command file. An example is delivered in the CFT_PKI: directory.
PKIUTIL #CFT-PKI.CONF --> creates PKI base and inserts the certificates PKIUTIL LISTPKI --> lists the inserted certificates
Transfer CFT OpenVMS 3.3.2 Installation Guide 103 Migrate, upgrade, update 4
Overview This section is designed to assist administrators or users who are tasked with upgrading or migrating from an existing Transfer CFT version to Transfer CFT 3.3.2.
The Transfer CFT versions that are available to migrate include 2.4, 2.7, 3.0.1 and 3.1.3.
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.
Migrate, update, and upgrade
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.3.2 SP1 to Transfer CFT 3.3.2 SP3.
Migration options The following methods are available for updating your Transfer CFT product version.
l Upgrade (existing)
l Manual migration
About upgrades An upgrade is the process of updating to a newer, enhanced version of the software.
For more information, go to Upgrade to Transfer CFT 3.3.2 or Upgrading a Transfer CFT 3.0.1 or 3.1.3 multi-node installation.
This mode has the following advantages:
l Allows you to update in the same location
l You can perform this upgrade yet still revert to the previous state if needed
l Scripts and APIs remain intact and only require a recompilation for the APIs
Transfer CFT OpenVMS 3.3.2 Installation Guide 104 4 Migrate, upgrade, update
About migrations A migration means that an initial Transfer CFT is installed in a directory that is not removed or overwritten by the procedure.
This mode has the following advantages:
l The new installation occurs in a new location, and the existing configuration in the existing Transfer CFT environment is not affected
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 manual migrations The manual migration procedure, used to migrate an existing Transfer CFT to Transfer CFT 3.3.2, is described in this document.
The general procedure for migrating from a previous version of Transfer CFT to Transfer CFT 3.3.2 is:
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 it is manual, you can customize as needed.
l You can manually migrate from versions older than version 2.7.x.
Check product details You can use the display command to check the version, or product details prior to updating.
The display command lists Transfer CFT OpenVMS product information.
CFTUTIL about
More information If you encounter issues when migrating Transfer CFT, contact Axway Sphere at support.axway.com.
Transfer CFT OpenVMS 3.3.2 Installation Guide 105 4 Migrate, upgrade, update
Before you start Prior to performing an upgrade or migration, you must:
l Update your Transfer CFT to the most recent service pack version.
l Backup Transfer CFT before beginning the procedure.
l Stop the existing version of Transfer CFT and the Copilot (UI) server.
Note 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.
Caution For versions prior to and including Transfer CFT 2.6.4 SP1, there are export issues if you are using intermediate certificates that have a different ID. A fix was delivered in Transfer CFT 2.4.1 SP11 to correct this PKI export issue.
License key requirement You require a new license key if you are migrating from a version 2.x Transfer CFT to a version 3.x.
Transfer CFT OpenVMS 3.3.2 Installation Guide 106 4 Migrate, upgrade, update
Update Transfer CFT This section describes how to perform the following Transfer CFT tasks in an OpenVMS environment:
l Apply a service pack
l Remove a service pack
l Apply a patch
l Remove a patch
Apply a service pack
1. Download the service pack from Axway support at support.axway.com to the machine you want to update. 2. Stop the servers that you want to update. 3. Transfer the service pack to the host in binary mode. 4. Extract the zip file using the following command, where you replace the SP number with the most recent SP:
unzip Transfer_CFT_3.3.2_SP1_vms-ia64.zip
5. Load the Transfer CFT profile.
6. Run the system command @SYS$UPDATE:VMSINSTAL:
SET DEF [.Transfer_CFT_V3.3.2_vms-ia64.install] @SYS$UPDATE:VMSINSTAL CFT033
############################################### ### Upgrading of an existing CFT account... ### ###############################################
7. In the Installation options screen, enter 1 to update Transfer CFT OpenVMS:
Installation options - Installing the Service Pack : 1 - Uninstalling the Service Pack : 2 - Link product : 3 * Option selected [1]:
8. Reconnect to the Transfer CFT profile. 9. Use the CFTUTIL ABOUT command to check that Transfer CFT OpenVMS was successfully upgraded.
Note
Transfer CFT OpenVMS 3.3.2 Installation Guide 107 4 Migrate, upgrade, update
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.
Remove a service pack This section describes how to uninstall a service pack, which you can do using the console mode in OpenVMS environments.
1. Stop Transfer CFT. 2. Load the Transfer CFT profile.
3. Run the system command: @SYS$UPDATE:VMSINSTAL
4. In the Installation options screen, enter 2 to uninstall the service pack:
Installation options Installing the Service Pack : 1 Uninstalling the Service Pack : 2 Link product : 3 * Option selected [2]:
5. Reconnect to the Transfer CFT profile. 6. Use the CFTUTIL ABOUT command to check that the service pack was successfully uninstalled.
Apply a patch
1. Download the product update from Axway support at support.axway.com to the machine you want to update. 2. Stop the servers that you want to update. 3. Transfer the patch to the host in binary mode. 4. Extract the zip file using the following command, where you replace the SP and Patch number with the most recent SP and patch numbers. Notice that the -a option converts the text file to a VMS format.
unzip -a Transfer_CFT_3.3.2-SP1_Patch1_vms-ia64.zip
5. Load the Transfer CFT profile. 6. Execute the KITUPDATE.COM script to apply the patch:
SET DEF [.install] @KITUPDATE.COM INSTALL
Transfer CFT OpenVMS 3.3.2 Installation Guide 108 4 Migrate, upgrade, update
7. Reconnect to the Transfer CFT profile. 8. Use the CFTUTIL ABOUT command to check that the patch was successfully applied.
Remove a patch This section describes how to uninstall a patch using the console mode in OpenVMS.
1. Stop Transfer CFT. 2. Load the Transfer CFT profile. 3. Run the system command:
SET DEF [.install] @KITUPDATE.COM UNINSTALL
4. Reconnect to the Transfer CFT profile. 5. Use the CFTUTIL ABOUT command to check that the patch update was removed.
Transfer CFT OpenVMS 3.3.2 Installation Guide 109 4 Migrate, upgrade, update
Manually upgrade Transfer CFT This section explains how to upgrade an existing Transfer CFT from 2.7.1, 3.0.1, 3.1.3, or 3.2.4 to a Transfer CFT 3.3.2.
Before you start Before beginning the upgrade procedure, you should:
l Check that you have the Transfer CFT Upgrade Pack available for download from Axway Sphere at support.axway.com.
l Stop the Transfer CFT server and the Transfer CFT Copilot (UI) server. Enter:
cftstop copstop -f
Display product details You can use the display command to check the version or product details prior to upgrading.
CFTUTIL about
Manually upgrade a single installation The manual upgrade procedure is similar to the migration procedure, and consists of:
1. Load the former Transfer CFT 2.7.1, 3.0.1, 3.1.3, or 3.2.4 environment. 2. Stop Transfer CFT. 3. Create a temporary directory for your exported configuration:
create/dir DKB200:[CFT_EXPORT] SET DEF DKB200:[CFT_EXPORT]
4. Export your configuration.
l Export your static configuration objects using the command CFTUTIL CFTEXT:
CFTUTIL CFTEXT type=all, fout=cft-extract.conf
l Export your PKI certificates using the PKIUTIL PKIEXT command. Enter:
Transfer CFT OpenVMS 3.3.2 Installation Guide 110 4 Migrate, upgrade, update
PKIUTIL PKIEXT fout=pki-extract.conf
l Export the catalog using the CFTMI command. Enter:
CFTMI MIGR type=CAT, direct=FROMCAT, ifname=CFTCATA, ofname=catalog_output.xml
l Export the communication media file using the CFTMI command:
CFTMI MIGR type=COM, direct=FROMCOM, ifname=CFTCOM, ofname=com_output.xml
l You must also export procedures that are specific to your production, sample APIs, exits, execs, etc.
o Copy your API, and exit sources.
o Copy your exec and specific scripts.
Note Note You must recompile these after upgrading.
5. Rename your Transfer CFT directory environment.
l Rename the INSTALL directory:
SH LOG CFTDIRINSTALL RENAME DKB200:[CFTREF.CFT332.CFT]HOME.DIR DKB200:[CFTREF.CFT332.CFT]HOME_SAVE.DIR
l Rename the RUNTIME directory :
SH LOG CFTDIRRUNTIME RENAME DKB200:[CFTREF.CFT332.CFT]RUNTIME.DIR DKB200:[CFTREF.CFT332.CFT]RUNTIME_SAVE.DIR
6. You can now install the new Transfer CFT version. See Installing Transfer CFT on a single host on page 14. 7. Import the configuration.
l Import the configuration that you saved previously in the temporary directory created in Step 3.
SET DEF DKB200:[CFT_EXPORT]
l Import your static configuration objects using the command:
cftinit cft-extract.conf
l Import your PKI certificates using the PKIUTIL command. Enter:
Transfer CFT OpenVMS 3.3.2 Installation Guide 111 4 Migrate, upgrade, update
PKIUTIL PKIFILE fname=CFTPKU, mode='CREATE’ PKIUTIL @pki-extract.conf
l Import the catalog using the CFTMI command. Enter:
CFTM MIGR type=CAT, direct=TOCAT, ifname=catalog_output.xml, ofname=CFTCATA
l Import the communication media file using the CFTMI command:
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml, ofname=CFTCOM
l Import specific procedures to your production, for example APIs, EXITs, execs, etc.:
o Copy your API and EXIT sources.
o Copy your exec and specific scripts.
Note You must recompile these after upgrading.
Check the new version To check the Transfer CFT version, as well as the license key and system information, enter:
CFTUTIL about
Manually upgrade a Transfer CFT multi-node installation The multi-node procedure is similar to the non-multinode procedure. However, when exporting CAT and COM, you must export your configuration for each node.
1. Load the former Transfer CFT 2.7.1, 3.0.1, 3.1.3, or 3.2.4 environment. 2. Stop Transfer CFT OpenVMS. 3. Create a temporary directory for your exported configuration:
create/dir DKB200:[CFT_EXPORT] SET DEF DKB200:[CFT_EXPORT]
4. Export your configuration.
l Export your static configuration objects using the command CFTUTIL CFTEXT:
CFTUTIL CFTEXT type=all, fout=cft-extract.conf
Transfer CFT OpenVMS 3.3.2 Installation Guide 112 4 Migrate, upgrade, update
l Export your PKI certificates using the PKIUTIL PKIEXT command. Enter:
PKIUTIL PKIEXT fout=pki-extract.conf
l Export the catalog using the CFTMI command. Enter:
CFTMI MIGR type=CAT, direct=FROMCAT, ifname=
l Export the communication media file using the CFTMI command:
o For each communication media file, enter:
CFTMI MIGR type=COM, direct=FROMCOM, ifname=
o For each node, enter:
CFTMI MIGR type=COM, direct=FROMCOM, ifname=
l You must also export procedures that are specific to your production, for example APIs, exits, execs, etc.
o Copy your API and exit sources.
o Copy your exec and specific scripts.
Note You must recompile these after upgrading.
5. Rename your Transfer CFT directory environment for each hostname.
l For the first hostname (n°1):
o Rename the INSTALL directory:
SH LOG CFTDIRINSTALL RENAME DKB200:[HOST1.CFT332.CFT]HOME.DIR DKB200:[ HOST1.CFT332.CFT]HOME_SAVE.DIR
o Rename the RUNTIME directory:
SH LOG CFTDIRRUNTIME RENAME DKB400:[SHARED.CFT332.CFT]RUNTIME.DIR DKB400:[SHARED.CFT332.CFT]RUNTIME_SAVE.DIR
Transfer CFT OpenVMS 3.3.2 Installation Guide 113 4 Migrate, upgrade, update
l For each additional hostname (n°x):
o Rename the INSTALL directory:
SH LOG CFTDIRINSTALL RENAME DKA100:[HOST2.CFT332.CFT]HOME.DIR DKA100:[ HOST2.CFT332.CFT]HOME_SAVE.DIR
6. You can now install the new Transfer CFT version. See Installing Transfer CFT on multiple hosts on page 25. 7. Import the configuration that you saved previously in the temporary directory created in Step 3.
SET DEF DKB200:[CFT_EXPORT] 8.
l Import the static configuration objects using the command:
PKIUTIL PKIFILE fname=CFTPKU, mode='CREATE’ PKIUTIL @pki- extract.conf
l Import the PKI certificates using the PKIUTIL command:
PKIUTIL PKIFILE fname=CFTPKU, mode='CREATE’ PKIUTIL @pki-extract.conf
l Import the catalog using the CFTMI command:
CFTM MIGR type=CAT, direct=TOCAT, ifname=catalog_output_
l Import the communication media file using the CFTMI command:
o For each communication media file, enter:
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml, ofname=
o For each node, enter:
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput_
l Import specific procedures to your production, for example APIs, EXITs, execs, etc.:
o Copy your API and EXIT sources.
o Copy your exec and specific scripts.
Note You must recompile these after upgrading.
Transfer CFT OpenVMS 3.3.2 Installation Guide 114 4 Migrate, upgrade, update
Check the new version To check the Transfer CFT version, as well as the license key and system information, enter the command:
CFTUTIL about
Transfer CFT OpenVMS 3.3.2 Installation Guide 115 4 Migrate, upgrade, update
Migration prerequisites This section describes two basic steps that you perform when migrating Transfer CFT OpenVMS .
Prerequisites
Install Transfer CFT 3.3.2
1. Perform a Transfer CFT installation, as described in the installation section. 2. After installing Transfer CFT 3.3.2, update the to the most recent service pack.
Load the environment Before beginning the manual migration procedure, you must load the former (old) Transfer CFT environment. After loading the profile, you can execute commands from anywhere.
Check 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 you are using one of these cipher suites, and you perform a migration from a version lower than 3.2.0, you must set the UCONF parameter cft.ssl.version_max=tls_1.2.
Transfer CFT OpenVMS 3.3.2 Installation Guide 116 4 Migrate, upgrade, update
Migrate from Transfer CFT 2.4.1 This section describes how to migrate from Transfer CFT 2.4 to version 3.3.2. Before starting the migration procedure you must perform the steps described in Before you start on page 106.
Migrate the configuration
Migrate the main configuration Migrate the PARM, PART, IDF and other static configuration objects.
1. Load the Transfer CFT 2.4 environment. See the Before you start on page 106 for details.
2. Export your static configuration objects using the CFTUTIL CFTEXT command. 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. Import your static configuration objects using the cftinit command. Enter:
cftinit cft-extract.conf
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.
2. Create a script file, for example: trkapi-import.com
3. For each parameter you select, add a UCONF command line to your new script file using the format:
UCONFSET id=
Use the parameter mapping between trkapi and UCONF, as shown in the following table, to specify the correct parameter id.
Transfer CFT OpenVMS 3.3.2 Installation Guide 117 4 Migrate, upgrade, update
Table 1. Trkapi.cfg file to UCONF parameter mapping
Parameter in trkapi.cfg UCONF parameter
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
XFB.Log (UNIX) sentinel.xfb.log
XFBLOG (Windows) sentinel.xfb.log
XFB.Sentinel sentinel.xfb.enable
XFB.Trace sentinel.xfb.trace
XFB.Transfer sentinel.xfb.transfer
4. Load the Transfer CFT 3.3.2 environment.
5. Import the selected UCONF parameters using the CFTUTIL command. Replace
CFTUTIL
Example
CFTUTIL @trkapi-import.com
Migrate 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 to version 3.3.2.
2. Create a script file, for example: copconf-import.com
Transfer CFT OpenVMS 3.3.2 Installation Guide 118 4 Migrate, upgrade, update
3. For each selected parameter add a UCONF command line in your new script file using the format:
UCONFSET id=
Use the parameters mapping between copconf and UCONF as shown in the following table to specify the correct parameter id.
Table 2. Copconf file to UCONF parameter mapping
Parameter in UCONF parameter copconf.ini
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
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
Transfer CFT OpenVMS 3.3.2 Installation Guide 119 4 Migrate, upgrade, update
Parameter in UCONF parameter copconf.ini
wlogComment copilot.batches.wlog.comment
wlogParams copilot.batches.wlog.params
WsiComplience copilot.webservices.wsicomplience
4. Load the Transfer CFT 3.3.2 environment.
5. Import the selected UCONF parameters using the CFTUTIL command. Replace the
CFTUTIL
Example
CFTUTIL @copconf-import.com
Migrate PKI certificates 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 PKIUTIL PKIEXT command:
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
PKIUTIL PKIFILE fname=CFTPKU, mode='CREATE’
5. If an error occurs when importing your certificate, for example:
PKIU20I DDecode_Cert : Failure, Unable to get info about the certificate PKIU26E PKICER _ Error ( PKI decipher error {15026/0} (pkider(): Failed to decode DER certificate) ) PKIU00I PKICER _ Failed (ID='CAXMP',ROOTCID='CAXMP',ITYPE='ROOT',COMMENT='S PKIU00I AMPLE
Transfer CFT OpenVMS 3.3.2 Installation Guide 120 4 Migrate, upgrade, update
CA',INAME='ROOT0001.',IFORM='DER',MODE='REPL PKIU00I ACE') PKIU00I RETURN _ Correct (CODE=8) PKIU20I Number of Command(s) 1
You can convert your certificate using the following command before importing the certificates:
SET FILE/ATTRIB=(LRL:4096,RFM:UDF)
Example
SET FILE/ATTRIB=(LRL:4096,RFM:UDF) USER*.* SET FILE/ATTRIB=(LRL:4096,RFM:UDF) ROOT*.*
6. Import your PKI certificates to Transfer CFT 3.3.2 using the PKIUTIL command. Replace the
PKIUTIL
Example
PKIUTIL @pki-extract.com
Migrate the runtime environment
Migrate the catalog
1. Load the Transfer CFT 2.4 environment. 2. Define the symbolic variable:
CFTMI240 == "$CFT_EXE:CFTMI240"
3. Export the catalog using the CFTMI240 command:
CFTMI240 MIGR type=CAT, direct=FROMCAT, ifname=CFTCATA, ofname=catalog_output.xml
4. Load the Transfer CFT 3.3.2 environment.
5. Import the catalog using the CFTMI command. The ofname should be the corresponding environment variable, in this case CFTCATA.
Transfer CFT OpenVMS 3.3.2 Installation Guide 121 4 Migrate, upgrade, update
CFTMI MIGR type=CAT, direct=TOCAT, ifname=catalog_output.xml, ofname=CATA
Migrating the communication media files
1. Load the Transfer CFT V2.4 environment. 2. Define the symbolic name:
CFTMI240 == "$CFT_EXE:CFTMI240"
3. Export the communication media file using the CFTMI240 command:
CFTMI240 MIGR type=COM, direct=FROMCOM, ifname=CFTCOM, ofname=com_output.xml
4. Load the Transfer CFT 3.3.2 environment.
5. Import the communication media file using the CFTMI command. Use the corresponding environmental variable as the ofname, in this case CFTCOM. Enter:
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml, ofname=CFTCOM
Transfer CFT OpenVMS 3.3.2 Installation Guide 122 4 Migrate, upgrade, update
Migrate from Transfer CFT 2.7 This section describes how to migrate Transfer CFT 2.7 to version 3.3.2.
Note Be sure to first read the Before you start on page 106.
Migrate 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 Migration prerequisites on page 116 for details.
2. Export your static configuration objects using the CFTUTIL CFTEXT command. 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 new Transfer CFT 3.3.2 installation. 4. Load the new Transfer CFT 3.3.2 environment.
5. Import your static configuration objects using the cftinit command. Enter:
cftinit cft-extract.conf
Migrate the PKI certificates
1. Load the former Transfer CFT 2.7 environment. 2. Export your PKI certificates using the command PKIUTIL PKIEXT. Enter:
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 PKIUTIL PKIFILE command. Replace
PKIUTIL PKIFILE fname=CFTPKU, mode='CREATE’
5. Convert your certificate with the following command.
SET FILE/ATTRIB=(LRL:4096,RFM:UDF)
Transfer CFT OpenVMS 3.3.2 Installation Guide 123 4 Migrate, upgrade, update
6. Import your PKI certificates in the new Transfer CFT 3.3.2 using the PKIUTIL command. Replace the
PKIUTIL
Example
PKIUTIL @pki-extract.conf
Migrate the runtime environment
Migrate the catalog
1. Load the former Transfer CFT 2.7 environment. 2. Define the symbolic variable:
CFTMI240 == "$CFT_EXE:CFTMI240"
3. Export the catalog using the CFTMI240 command.
CFTMI240 MIGR type=CAT, direct=FROMCAT, ifname=CFTCATA, ofname=catalog_output.xml
4. Load the new Transfer CFT 3.3.2 environment. 5. Import the catalog using the command CFTMI. Replace the
Example
CFTMI MIGR type=CAT, direct=TOCAT, ifname=catalog_output.xml, ofname=CFTCATA
Migrate the communication media files
1. Load the former Transfer CFT 2.7.0 environment.
2. Export the communication media file using the CFTMI240 command.
CFTMI240 MIGR type=COM, direct=FROMCOM, ifname=
3. Load the new Transfer CFT 3.3.2 environment.
Transfer CFT OpenVMS 3.3.2 Installation Guide 124 4 Migrate, upgrade, update
4. Import the communication media file using the CFTMI command. Use the corresponding environment variable for the ofname, in this case CFTCOM.
Example
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml, ofname=CFTCOM
Transfer CFT OpenVMS 3.3.2 Installation Guide 125 4 Migrate, upgrade, update
Migrate from Transfer CFT 3.0.1, 3.1.3, or 3.2.4 This section describes how to migrate Transfer CFT 3.0.1, 3.1.3, 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 describes migration for a multi-node architecture. Lastly, there are instructions explaining what would be needed to migrate from a single-node architecture to multi node architecture.
Be sure to first read the Before you start on page 106.
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
Migrate the configuration
Migrate the main configuration and UCONF parameters Migrate the PARM, PART, IDF, other static configuration objects, and UCONF parameters as follows:
1. Load the former Transfer CFT 3.0.1, 3.1.3, or 3.2.4 environment. See the Before you start on page 106 for details.
2. Export your static configuration objects using the CFTUTIL CFTEXT command. Enter:
CFTUTIL CFTEXT type=all, fout=cft-extract.conf
3. Open the extracted configuration files, cft-extract.conf, and update the file paths with those of the new Transfer CFT 3.3.2 installation. 4. Load the Transfer CFT 3.3.2 environment.
5. Import your static configuration objects using the cftinit command. Enter:
cftinit cft-extract.conf
Migrate the PKI certificates
1. Load the former Transfer CFT 3.0.1, 3.1.3, or 3.2.4 environment.
2. Export your PKI certificates using the PKIUTIL PKIEXT command. Enter:
PKIUTIL PKIEXT fout=pki-extract.conf
3. Load the Transfer CFT 3.3.2 environment.
Transfer CFT OpenVMS 3.3.2 Installation Guide 126 4 Migrate, upgrade, update
4. Create a new PKI internal datafile using the PKIUTIL PKIFILE command.
PKIUTIL PKIFILE fname=CFTPKU, mode='CREATE’
5. Import your PKI certificates into Transfer CFT 3.3.2 using the PKIUTIL command. Replace the
PKIUTIL
Migrate the runtime environment
Migrate the catalog
1. Load the former Transfer CFT 3.0.1, 3.1.3, or 3.2.4 environment.
2. Export the catalog using the CFTMI command. Enter:
CFTMI MIGR type=CAT, direct=FROMCAT, ifname=CFTCATA, ofname=catalog_output.xml
Load Transfer CFT 3.3.2 environment.
Import the catalog using the CFTMI command.
CFTM MIGR type=CAT, direct=TOCAT, ifname=catalog_output.xml, ofname=CFTCATA
Migrate the communication media files
1. Load the former Transfer CFT 3.0.1, 3.1.3, or 3.2.4 environment.
2. Export the communication media file using the CFTMI command.
CFTMI MIGR type=COM, direct=FROMCOM, ifname=CFTCOM, ofname=com_output.xml
3. Load the Transfer CFT 3.3.2 environment.
4. Import the communication media file using the CFTMI command.
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml, ofname=CFTCOM
Transfer CFT OpenVMS 3.3.2 Installation Guide 127 4 Migrate, upgrade, update
Multi node architecture
Migrate the configuration
Migrate the main configuration and UCONF parameters Migrate the PARM, PART, IDF, other static configuration objects, and UCONF parameters as follows:
1. Load the former Transfer CFT 3.0.1, 3.1.3, or 3.2.4 environment.
2. Export your static configuration objects using the CFTUTIL CFTEXT command. 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 new Transfer CFT 3.3.2 installation. 4. Load the Transfer CFT 3.3.2 environment.
5. Import your static configuration objects using the cftinit command. Enter:
cftinit cft-extract.conf
Migrate the PKI certificates
1. Load the former Transfer CFT 3.0.1, 3.1.3, or 3.2.4 environment.
2. Export your PKI certificates using the PKIUTIL PKIEXT command. Enter:
PKIUTIL PKIEXT fout=pki-extract.conf
3. Load the Transfer CFT 3.3.2 environment.
4. Create a new PKI internal datafile using the PKIUTIL PKIFILE command. Replace
PKIUTIL PKIFILE fname=
5. Import your PKI certificates to Transfer CFT 3.3.2 using the PKIUTIL command. Replace the
PKIUTIL
Transfer CFT OpenVMS 3.3.2 Installation Guide 128 4 Migrate, upgrade, update
Migrate the runtime environment
Migrate the catalog
1. Load the former Transfer CFT 3.0.1, 3.1.3, or 3.2.4 environment.
2. Use the CFTMI command to export all catalogs, one per node (named cftcataXX, where XX is the node number having a range from 00 to the
CFTMI MIGR type=CAT, direct=FROMCAT, ifname=
3. Load the Transfer CFT 3.3.2 environment. 4. Import all catalogs using the CFTMI command for each. Use the same node number on both
CFTM MIGR type=CAT, direct=TOCAT, ifname=catalog_output_
Migrate the communication media files
1. Load the former Transfer CFT 3.0.1, 3.1.3, or 3.2.4 environment. 2. Use the CFTMI command to export all communication media files (cftcom and cftcomXX, where XX is the node number having a range from 00 to
l For each communication media file, enter:
CFTMI MIGR type=COM, direct=FROMCOM, ifname=
l For each node, enter:
CFTMI MIGR type=COM, direct=FROMCOM, ifname=
3. Load Transfer CFT 3.3.2 environment.
4. Import all communication media files using the CFTMI command for each of them. Use the same node number for both
Transfer CFT OpenVMS 3.3.2 Installation Guide 129 4 Migrate, upgrade, update
l Enter:
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput.xml, ofname=
l For each node, enter:
CFTMI MIGR type=COM, direct=TOCOM, ifname=com_ouput_
Single node to multi-node architecture The only difference between migrating from a single node to multi-node architecture, and migrating from single node to single node architecture is the catalog migration step. Since there is no CFTCATA catalog in multi-node, you should import the catalog exported from the single node architecture to each of the node catalogs in your multi-node architecture.
Transfer CFT OpenVMS 3.3.2 Installation Guide 130 Uninstall Transfer CFT 5
This topic describes how to uninstall Transfer CFT. If you uninstall a Transfer CFT, you will lose the complete Transfer CFT configuration. To avoid this, save your environment (sample, exit, …) before removing the Transfer CFT OpenVMS.
There is no automatic procedure to uninstall Transfer CFT OpenVMS; you must perform system commands to delete all files as described here.
1. Identify the Transfer CFT directories to delete it with the command: sh log D$CFT_INST
sh log D$CFT_RUN
"D$CFT_INST" = "DKB200:[CFT.HOME.]" "D$CFT_RUN" = " DKB400:[CFT.SHARED.CFT.RUNTIME.]"
2. Use and repeat the delete command to remove all Transfer CFT OpenVMS files.
delete DKB200:[CFT.HOME…]*.*;* delete DKB400:[CFT.SHARED.CFT.RUNTIME…]*.*;*
3. After you have deleted all files, delete the home and runtime directories:
delete DKB200:[CFT]HOME.DIR;* delete DKB400:[CFT.SHARED.CFT]RUNTIME.DIR;*
4. Check that all directories are removed. 5. Delete the Transfer CFT user for this installation if no longer need.
Transfer CFT OpenVMS 3.3.2 Installation Guide 131 Troubleshooting 6
Troubleshooting This section describes common errors when using Transfer CFT, and the tools available to troubleshoot the Transfer CFT product.
Overview You can use the following tools to understand and correct the most frequently encountered problems when using Transfer CFT.
If you detect a Transfer CFT activity problem during operations, use the following tools to troubleshoot:
l Transfer CFT catalog
l Transfer CFT log file (CFTLOG)
l CFTMAIN batch or process LOG file (CFT_LOG:CFTMAIN.LOG)
l Monitor configuration files and/or parameters extracted from the Transfer CFT parameter and partner files
In some cases, such as when Transfer CFT cannot be started, unexpectedly shuts down, or a process trap occurs, you may need the following elements to provide additional information to identify and correct the problem:
l *.OUT and *.ERR files generated by the various Transfer CFT processes in the SYS$LOGIN directory of the Transfer CFT account
l Dump file(s) (*.DMP) generated by VMS in the CFT_EXE: directory following a trap on one of the Transfer CFT processes
l Various diagnostic elements supplied by OpenVMS, which are used to trace system events:
l Error Log File
l Operator Log File
l Accounting Log File
l ANALYSIS/AUDIT report
The Technical Support Team may request that internal traces be implemented. This feature is not fully documented for the user. It consists of a series of commands to be submitted using the CFTUTIL utility, on the instructions of the Technical Support Team. You will need to provide the elements requested, so that the team can determine the problem.
Transfer CFT OpenVMS 3.3.2 Installation Guide 132 6 Troubleshooting
The procedures to be followed by the Transfer CFT manager vary according to the type of problem detected. Problems can generally be classed under two categories:
l The problem is related to a transfer or specific type of transfer, but does not stop all production
l The problem is Transfer CFT-related and blocks all or part of the transfer operations
Transfer related problems These problems cause Transfer CFT to abort a transfer. For the Transfer CFT operator, one or more transfers fail, but the remaining activity is normal. This may be an exceptional or recurring phenomenon.
The key diagnostic elements are the Transfer CFT catalog and log file.
The problem may be local and due to the transfer configuration (CFTSEND and CFTRECV commands), the network resource configuration (CFTNET command), the protocol configuration (CFTPROT command), production problems (quotas, privileges, file or network problems) or the protocol-level dialog with your partner.
Querying the catalog Once you have identified the transfer at fault, query the catalog. The DIAGI field provides global information on the source of the error. Some of these codes are protocol-specific.
When the error is local, that is the error condition causing the transfer to be aborted occurred on your system, the DIAGP field in the catalog provides additional system-specific information. Otherwise, the DIAGP field contains a code that is standardized for the protocol between you and the partner site.
The DIAGI codes corresponding to local and remote errors range from 0 to 499 and 600 to 999 respectively. If a remote error occurs, you must contact the partner site, so that you can both determine the cause of the error. The error can be corrected by taking action on either side of the link.
The various types of error that can occur locally during a transfer are:
l Internal monitor errors: DIAGI code between 0 and 3
l Errors relating to transferred files: DIAGI code between 100 and 142
l Errors in the protocol-level dialog between the two transfer monitors: DIAGI code between 220 and 240
l Network-related errors: DIAGI code between 301 and 303
l Monitor configuration errors: DIAGI code between 401 and 460
l Non-referenced errors: DIAGI code equal to 399
The way in which the DIAGP field is interpreted varies according to the type of error. To determine the meaning of the code, refer to the sub-book Codes, Diagnostics and Messages in the Transfer CFT online documentation.
Transfer CFT OpenVMS 3.3.2 Installation Guide 133 6 Troubleshooting
Querying the Transfer CFT log file The transfer record may not appear in the catalog, even though the partner site has informed you of a problem, or the intended transfer has not been performed. This is often the case in server mode, when the problem occurs even before the transfer starts (mutual identification refused, file creation error, and so on). Therefore, you must query the Transfer CFT log file.
The Transfer CFT log file contains a trace of all events that occurred during monitor operations from the last file switch.
The sub-book Messages in the Codes, Diagnostics Codes and Messages in the Transfer CFT online documentation provides the format and a description for each event.
TCP/IP network In the case of the TCP/IP network, reason and diagnostic codes are returned by the task serving the TCP/IP network for Transfer CFT. The code structure is specific to CFT. For more information refer to TCP/IP Network, in Network Codes in the Transfer CFT online documentation.
Interpreting a system code A code in the CS, NCS or SCS category is a code that has been returned by the system service used to perform the operation that caused the error. Transfer CFT displays the code in hexadecimal format.
The system code is specific to OpenVMS and is therefore not documented in the Transfer CFT guides. To determine the meaning, you must refer to the OpenVMS System Messages and Recovery Procedures Reference Manual. The error codes are listed with their mnemonics.
To obtain the mnemonic from the code, proceed as follows:
$ write sys$output f$message("%x00018292") %RMS-E-FNF, file not found $
You can often determine the cause of the error from this code and take corrective action.
Interpreting a network code When the error is network-related (DIAGI code between 301 and 303), the DIAGP field is defined with a code specific to the type of network used.
The various network accounting files may feature additional information on the cause of the error.
If the error is indicated as being local (the code has the L HH HHH format), the reason and diagnostic fields do not correspond to network-standard codes. It is a problem related to the use of the network interface and not of the network itself.
Transfer CFT OpenVMS 3.3.2 Installation Guide 134 6 Troubleshooting
If the reason code is equal to 2, the diagnostic code may be 1 or 2. If the reason code is equal to 3, the diagnostic code is a system code, depending on the type of problem.
The following table describes the reason and diagnostic codes.
Reason Diagnostic Meaning Action
2 1 Internal memory allocation Increase the JOB PGFLQUOTA or problem. implement the memory control Insufficient dynamic memory mechanism, refer to section 3.2. for the JOB.
2 2 Maximum number of VCs Modify your subscription and declared for the resource increase the value of the CFTNET (configuration CFTNET command MAXCNX parameter command) reached. defining the network resource, or wait until one of the VCs of the resource used is released for another transfer.
3 System System code returned by the According to the meaning of the code network access system services. code, refer to the OpenVMS To determine the meaning of guide entitled System Messages this code, refer to paragraphs and Recovery Procedures. SYS$QIO, SYS$ASSIGN, SYS$CANCEL and SYS$DASSGN in the System Services Reference Manual, or the programming guide for the corresponding network.
Production related problems Problems can occur that are not specifically related to a transfer or group of transfers, such as:
l The monitor cannot be started up
l The dynamic processes cannot be initialized
l Monitor activities appear to be blocked
l Some functions are not performed (procedures, and so on)
l Communications cannot be established with the monitor
l Certain processes are missing
l Network errors recur
Most malfunctions are caused by a Transfer CFT configuration error, incorrectly defined quotas or privileges for the Transfer CFT account, inappropriately sized system parameters (such as GBLPAGES and GBLSECTIONS), and so on.
Transfer CFT OpenVMS 3.3.2 Installation Guide 135 6 Troubleshooting
You can obtain information on the type of problem from the Transfer CFT log file.
If the problem is related to the use of an internal system service, you can find more information by querying the standard output files for the Transfer CFT tasks.
For the main CFTMAIN JOB process, consult either the batch report (CFT_LOG:CFTMAIN.LOG) or the files designated as output and error files if Transfer CFT is created as a detached process.
For Transfer CFT sub-processes, consult the .OUT and .ERR files in the Transfer CFT account login directory (SYS$LOGIN).
System call error messages The specific part of Transfer CFT uses the OpenVMS system services to perform the operations required by Transfer CFT. If a call fails, an error message is sent to the standard output file of the process.
This message comprises:
l The date and time at which the error occurred
l The name of the internal service concerned
l A specific section of text describing the error
The message text may include the following symbolic variables:
l &cs: code returned by the system service
l &chan: OpenVMS channel number
l &cr: monitor-specific return code
l &str: character string used by the service
l &evt: character string representing the network event
l &ref: reference to an internal monitor context
l &val: decimal value
l &net: type of network used
Values between square brackets ([...]) are expressed in hexadecimal, others in decimal.
For all these messages, when the message label refers to the &cs symbolic variable, it is a code returned by the system service described in the message. To determine the meaning of this code and the action to be taken, refer to the guide OpenVMS System Messages and Recovery Procedure.
In all other cases, contact the Technical Support Team and provide all possible information to help troubleshoot the problem.
System messages common to all processes These messages correspond to service calls common to all Transfer CFT processes. They can be found in the standard output files of all processes in Transfer CFT.
Transfer CFT OpenVMS 3.3.2 Installation Guide 136 6 Troubleshooting
These messages correspond to common services specific to the Transfer CFT, but which call OpenVMS system services for execution purposes.
Shared memory manager messages
SIAM: create_section: SYS$CRMPSC.nom = &str.ret = &cs SIAM: create_section: section globale &str existante d une longueur differente SIAM: map_section: SYS$MGBLSC.1.nom = &str.ret = &cs SIAM: map_section: SYS$MGBLSC.2.nom = &str.ret = &cs
Memory manager messages
SIMM: gfree3: erreur lib buffer global.taille = &val SIMM: lalloc3: allocation.taille = &val SIMM: simmfg: ret = &cr SIMM: simmgg: liberation du 1/2 bloc.ret = &cr SIMM: simmgg: no de queue = &index SIMM: simmgg: ret = &cr.taille = &val
Inter-Task Communication Manager Messages
SISY: DEFINE: erreur allocation bloc semaphore.taille = &val SISY: DEFX: armement ast mbx.ret = &cs.ref = [&ref] SISY: DELX: mbx non trouvee.nom = &str SISY: POST: armement ast mbx.ret = &cs.ref = [&ref] SISY: POST: erreur allocation buffer global.taille = &val.ref = [&ref] SISY: POST: erreur allocation buffer local.taille = &val.ref = [&ref] SISY: POST: ref semaphore invalide.ref = [&ref] SISY: POST: semaphore detruit.ref = [&ref] SISY: WAIT: SYS$BINTIM.ret = &cs.ref = [&ref] SISY: WAIT: armement ast mbx.ret = &cs.ref = [&ref] SISY: WAIT: armement ast mbx.ret = &cs.status = &cs SISY: WAIT: erreur allocation buffer local.taille = &val.ref = [&ref] SISY: WAIT: erreur lecture mbx.ret = &cs.ref = [&ref] SISY: WAIT: ref semaphore invalide.ref = [&ref]
Transfer CFT OpenVMS 3.3.2 Installation Guide 137 6 Troubleshooting
SISY: WAIT: semaphore vide et compteur non nul.cpt = &val.ref = [&ref] SISY: ftype invalide: ftype = &val SISY: lock3: erreur allocation bloc process.taille = &val SISY: post3: armement ast mbx.ret = &cs.ref = [&ref] SISY: post3: erreur allocation buffer global.taille = &val.ref = [&ref] SISY: post3: erreur allocation buffer local.taille = &val.ref = &cs SISY: post3: ref semaphore invalide.ref = [&ref] SISY: post3: semaphore detruit.ref = [&ref]
Task Manager Messages
SITM: ATTACH: SYS$GETJPI.ret = &cs SITM: ATTACH: SYS$GETSYI.ret = &cs SITM: ATTACH: SYS$TRNLNM CFT_IMAGE.ret = &cs SITM: ATTACH: allocation bloc parametre SITM: ATTACH: creation du sous-process &str ret = &cs SITM: ATTACH: image inexistante &str SITM: ATTACH: nb max tache atteint SITM: INQ: bloc parametre introuvable SITM: ftype invalide: ftype = &val SITM: sitm_addr: 1er armement ast lecture mbx.ret = &cs.status = &cs SITM: sitm_addr: SYS$CREMBX.ret = &cs SITM: sitm_addr: SYS$GETDVIW.ret = &cs SITM: term_ast: armement ast lecture mbx.1.ret = &cs.status = &cs SITM: term_ast: armement ast lecture mbx.2.ret = &cs.status = &cs SITM: term_ast: bloc parametre introuvable SITM: term_ast: lecture mbx de terminaison.ret = &cs.status = &cs
CFTTFIL tasks system messages The following messages correspond to calls to services specific to transferred files input/output. They can only be found in the standard output files of the various CFTTFIL tasks.
Transfer CFT OpenVMS 3.3.2 Installation Guide 138 6 Troubleshooting
Network server tasks system messages The symbolic variables used:
l &NET: indicates that the message can be generated for all types of network
l &FCT: function processed when the error occurred (generally a network request)
l &msg: internal interchange block exchanged between the server task and CFTTPRO task
l &service: label for a system service used by the task
Transfer CFT OpenVMS 3.3.2 Installation Guide 139