Re: Ask the Expert: Best Practices for the z/OS Migrator Tool
What makes up a migration complex?
The migration complex consists of the z/OS Migrator database and all z/OS Migrator STCs registered in the database. There may be only one z/OS Migrator STC on an LPAR registered in any z/OS Migrator database. So the number of LPARs involved is equal to the number of z/OS Migrator STCs.
Owner vs Agent. Which z/OS Migrator is which and what does each do?
The owner, of a migration, is the z/OS Migrator STC which activates the group. An agent is any other z/OS Migrator STC that is part of that migration complex. Each z/OS Migrator STC is responsible for updates which occur on the LPAR it is running on. If the migration is a volume migration, the STCs are also responsible for any newly allocated datasets. The owner has additional tasks. It will coordinate the migration using the z/OS migrator database. Some commands must be given by the owner, for example the divert command for a logical migration. A preferred method of operation is to use the same Migrator started task as the owner as much as possible.
What is the z/OS migrator DB (database) used for and how is it accessed?
The z/OS Migrator DB contains information on each promoted migration group (Only a promoted group may be used to perform migrations). The DB is used to pass status, about active migrations, among the z/OS Migrator STCs in the migration complex. Each STC in turn will read and update the database. Access to the z/OS Migrator DB is expected to be controlled by a reserve on the volume it resides on. This means that 1) it will take some amount of time for group status to change. How long will depend on the number of LPARs involved in the migrator complex and how quickly the z/OS Migrator STCs on those LPARs can get access to the database. 2) The z/OS Migrator database should be the only active dataset on a volume. And 3) Since the volume the z/OS Migrator DB is on is ineligible for migrations, the DB should be placed on a volume on the target array.