Draft Document for Review February 7, 2020 3:15 pm 8464ch08_Migrate.fm GLYPH<SM590000> After a logical volume is accessed for update (by an append or a housekeeping process),  the logical volume cannot be copied again.  GLYPH<SM590000> GGM does not include any automatic interaction to the TMS. Depending on the scenario,  the workload profile, amount of data, and used TS7700 models, IBM recommends the use  of different approaches to select the sequence of the copies. GLYPH<SM590000> GGM is based on a  deferred copies  mechanism. Therefore, you must review your  CPYCNT parameter for the CTG because the Cluster Source Grid (CSG) might throttle  the GGM copies by using the values defined for DCOPYT and DCTAVGTD. The throttling  might affect the performance of the GGM copies. GLYPH<SM590000> The data placement in the CSG effects the performance of GGM. Recalls from physical  tape can slow down the process of GGM. Whenever possible, we suggest the use of a  TS7700D as the CSG. GLYPH<SM590000> The GGM tool also provides several different options, such as how the new data (new  device categories) and the old data (keep or delete the data in the source grid) is treated. GLYPH<SM590000> GGM from any grid to the grid that supports the new compression method is allowed. In  such a case, CTG can read logical volumes that are written by R4.1.1 or lower code level  in addition to volumes that are written by newer code levels. GLYPH<SM590000> GGM from the grid that supports the new compression method to the grid that does not  support it is not allowed. In such a case, CTG cannot read logical volumes migrated from  CSG. GLYPH<SM590000> The CSG is not subject to Deferred copy throttling because no host I/O is processed. GLYPH<SM590000> If the CSG is a TS7700T CPx, prestaging the data speeds up the GGM copy processing.  GLYPH<SM590000> Data with a short lifecycle can expire in the source grid without being copied at all to  reduce the amount of data that must be copied.  In general, we distinguish between two major logical scenarios for GGM.  The goal is to move the data from one grid to another, while the same LPARs with the origin  TCDB and TMS are used. After a single volume is copied, the information in the overlying  TCDB and TMC must be changed after a successful migration of the single logical volume.  These changes are the responsibility of the customer, and must be processed manually. In  this scenario, consider that a multivolume file can be accessed only if all logical volumes  belonging to the multivolume file are in the same grid.  We suggest switching the production workload to the new grid before you start the GGM  process. This switch includes several benefits: This scenario is mainly applicable if dedicated LPARs or workload of an LPAR must be  separated from an environment. which is usually necessary if a customer decides to change  to a different service provider, or if a company sells a subsidiary. In this case, the data is  copied over to a new grid. However, production is still running to the grid until a time called  cutover time .  Data movement with GGM Data duplication with GGM In this case, normally the TCDB and TMS are not changed during the copy process, but need  to be adjusted at cutover time, or before if cutover tests are made.  Also, it is necessary to copy the same logical volume multiple times because the lifecycle  processing of “create-expire-delete-cr eate” is running in the origin system.  306  IBM TS7700 Release 5.0 Guide