Problem

What are the recommendations for a migration from CFT 3.0.x to 3.2.x or 3.3.x

How to ensure the minimum downtime?

Best practice / use case in managing a Transfer CFT migration to a higher version

Resolution

1) First of all, ensure the Transfer CFT to migrate is at the latest SP (for 3.0.1, it is SP10). The migration procedures/tools make use of both source and target. In version 3.0.1 the latest SP includes fixes related to the migration tools.

2) Install CFT 3.x and it's latest SP on the side (using your favorite high qualifiers for that version).

• Verify if you you require the z/OS XML Toolkit v1.10 to implement CG, PassportAM or Web services
• Check if you have specificity in the SGINSTAL module (JOB A12OPTS) and report any changes in the target version.
• Verify if the new CFT LOADLIB need to be APF or not.
• Verify migration JOBs are up to date in the installation library in regards of the DISTLIB. You can use the JCL 'target.INSTALL(A13JCL)' for that operation:

Example:

//CUSTJCL EXEC PCUSTJ,OUT=&OUT,
// JCL='MIGRCAT,MIGRCOM', << for example
// LIB='INSTALL', << INSTALL
// QUAL=&CFTENV,
// UNIT=&SYSDA,
// DISTLIB=&DISTLIB

3) Migrate the parm and the part files from 3.0.1 to 3.x and ensure no more change will be done in 3.0.1 after the migration.

• Ensure all hard-coded file names (if any) are updated in the CFT parameters in regards of the CATALOG, PARM, PART, COM, PKI, LOGs, ACCOUNTs or take the opportunity to change for the benefit of using DDNAME.

4) Copy from CFT 3.x to CFT 3.0.1 both the PCFTUTL, PCFTUTIL and CFTENV procedures (theses are used in jobs from the LIB DD, the only point that link jobs to the CFT version 3.0.1

5) From here, CFT 3.0.1 is still usable as before but you are near to be ready to switch to 3.x

6) Get ready with updated start procedures for both CFT and Copilot (update existing ones if they are customized for your needs or simply use the ones proposed into the install library).

• Attention, in both Copilot and CFT STC, a new file is added with CFT3.x (see UCONFRUN)
• Attention, ensure Fault Analyzer invocation exits is turned off using the //IDIOFF DD DUMMY (in both Copilot and CFT STC, apply also to any other debugging tools)

7) At scheduled switch time, shutdown CFT 3.0.1, migrate the catalog and the com file.

8) Start CFT and Copilot 3.x, you are set and all jobs are ok

9) At a later time, even years later, update all CFT jobs with the right JCLLIB and maybe, enjoy the occasion to use the new variable &RUNTIMEDIR instead, it makes all jobs future-proof when upgrading CFT (no more change needed in the jobs).

//MYEOTJOB (),'TRANSFER_CFT',CLASS=A
//*
//LIB JCLLIB ORDER=(&RUNTIMEDIR.INSTALL)
// INCLUDE MEMBER=CFTENV

Your are set with the new version unless if like with Icebergs, the hidden face is important (exits, API, batches using CFT steplib instead of the JCLLIB, other programs?) that may need to be considered of course in advance.

Note1: Steps provide above are guideline only. Other migration approach may be retained.

Note2: Migration of the com and cat files is not always needed/wanted, there are alternatives.

• If the old com file get some commands during the switch (while CFT 3.0.1 is stopped), you can still add a second CFTCOM with that file to the new CFT so it will process all commands (up to 4 com files are supported).

• For the catalog, if the normal shut is done, so all transfers will be completed before CFT stop, you can choose to start with the new version using the fresh and empty catalog if you can live without wanting to track back transfers history from the new catalog. Anyway, details are still available from the old cat if needed.