Stat 6.3 - User Guide

Migrating File Objects

When an archive set contains file objects, the file archives are stored in the Stat repository. When you migrate the archive set to a PeopleSoft environment, Stat copies the file archives from the Stat Repository to the file locations defined for the target environment. If the file objects already reside in any of these source file locations, Stat replaces each existing instance with the archive copy. If the files exist in none of the source file locations, Stat either copies the files to all the source locations defined for the target environment or copies the files to the designated default location. These options are set up by system administrators when configuring the target environment.

To migrate file objects in an archive set to the developers’ working directories, you migrate the archive set to the Development environment. Stat gives you the option of migrating the file objects to the Development environment’s source file locations, the developers’ working directories, or to both. To migrate an archive set taken from the Development environment’s source file locations to the developer’s working directories, or vice versa, the migration must be initiated from the Archive Sets tab, not the Migration Path tab.

If two or more environments on a migration path share the same source file locations for a particular file type, whenever you migrate an archive set that contains file objects of that type to one of the environments, by default the file objects are also migrated to the other environment(s) that share the same source file locations. For example, if the Development environment and Test environment share the same source file locations for COBOL file objects, and you migrate an archive set containing a COBOL file object to Development, Stat documents that the same file object was also migrated to Test. This eliminates the time consuming process of having to perform multiple migrations in order to document the migration of the same file objects to each environment on the migration path.

IMPORTANT: Unix and Windows-based file servers have different formats for ASCII type file objects. Accordingly, when you migrate a ASCII type file object via SFTP, the Stat Central Agent checks its destination file server. If the server is Unix, the agent converts the file to the Unix ASCII format, which means singly occurring carriage returns followed by linefeed characters are converted to linefeed characters. If the destination server is Windows, the agent converts the file to the Windows ASCII format, which means singly occurring linefeed characters are converted to carriage returns followed by linefeed characters. In either case, the size of the migrated file may be smaller or larger than it was before it was migrated.

Migrating to Distributed Environments

When you migrate objects to a distribution environment, by default Stat migrates those objects to all the environments on its distribution list. However, you can opt to exclude certain environments from the migration.

When defining a migration path, system administrators designate distribution environments and add other environments to their distribution lists. For example, let’s say you have ten production environments and each one physically resides in a different location. All of your development work is done centrally, and when ready, changes are migrated out to all the production environments at the same time. Most likely your system administrator would define the local or ‘in-house’ production environment as the distribution environment and connect it to the nine other production environments.

Although connected to the distribution environment, the other environments are not represented graphically and are not technically part of the migration path. This means that objects cannot be locked in the environments on a distribution list. Also, objects can only be migrated to them, not from them.

TIP: Because objects are not locked when migrated to the environments connected to a distribution environment, it is recommended that your system administrator not include these environments in any other migration path. This eliminates the possibility of two developers accidentally overwriting each other’s work.

Graphically, distribution environments are designated by a small icon displayed to the left of the environment graphic, as shown below:

To view a listing of the environments connected to the distribution environment, double-click on the distribution icon. Stat opens the Distributed Environments window, which shows a list of all the environments connected to the distribution environment.

In this window, you can deactivate any environment you do not want to include in a migration. This way, when you migrate an archive set to a distribution environment, Stat migrates the objects only to the active environments in the distribution list. To deactivate all the environments, click Set All Inactive. If you want to reactivate an environment, you can do so at any time by selecting the Active check box, or if you want to reactivate all the environments, click Set All Active.

NOTE: Be aware of the following: • Deactivating an environment excludes it from any migration initiated from the current CSR. You can also exclude environments on a per-migration basis, which is addressed in the following section. • The user is required to have a security right that allows activating/inactivating distributed databases.

For more information see “PeopleSoft Environment Migration Path Maintenance,” in the Stat System Administration Guide, Chapter 5, “Service Domain- Specific Maintenance.”

For Stat to migrate PeopleSoft proprietary objects automatically to a distribution environment and its associated environments, the CLI Auto-Migration option must be activated for the distribution environment, as well as each environment on the distribution list. If the CLI Auto-Migration option is activated for just some of the environments in the distribution list, Stat migrates PeopleSoft proprietary objects only to those environments.

Also, Stat displays a warning message if it successfully completes a migration to a distribution environment but not to one or more of its associated environments (which would be the case if, for example, the password to one of the environments was incorrect). This information is also displayed in the Migration Details window. For more information, see Documenting Migrations (PeopleSoft) .

Running a Migration (PeopleSoft)

IMPORTANT: Before you can migrate an archive set into an environment that requires migration approval, one or more authorized users must approve the migration. For more information, see the section Migration Approvals and Mass Migrations (PeopleSoft) .

IMPORTANT: If the Development environment is a distribution environment and the archive set has both PeopleSoft proprietary objects and file objects selected for the migration, the option Working cannot be selected. To migrate file objects to Working, deselect the DB Objects option.

IMPORTANT: When migrating archive sets, bear in mind the following: • The base language of the staging database must be the same as the base language of the environment that the archive set came from (i.e., the source). • If the staging database you selected is currently in use, Stat displays a message telling you who is using the environment. You can retry the environment, select another environment, or if you have the proper security rights, click the Unlock button to unlock the environment. This deletes the other developer’s objects in the staging database and replaces them with yours.

NOTE: The Upgrade and Action values for objects in the archive set are not used when you use a PeopleSoft project contained in an archive set to perform the migration. In this case the Upgrade and Action values are set at the time you archived the project definition and the Upgrade and Action flags set in the archive set are ignored.

IMPORTANT: PeopleSoft project definitions are stored in the Stat Repository, and the only way to update a project definition is through the App Designer interface, which means that even if you change the archive set in Stat by adding or deleting objects, the project definition remains unchanged in Stat.

IMPORTANT: If you selected the Project in archive set option, you cannot modify the settings in the Upgrade Options window.

Auto-Migrating PeopleSoft Projects

If the CLI Auto-Migration feature has been enabled for the target environment (and you did not de-select the Auto Migration option), Stat launches PeopleSoft and tells PeopleSoft to copy the project from staging to target via a command line interface. While this is happening, you may see Application Designer login screen flash on your screen momentarily. For non-App Designer objects, Stat executes the DataMover import script. For more information on CLI options, see Setting Up Your PeopleSoft Connections .

If the archive set contains a PeopleSoft project definition and you have opted to migrate the archive set using a Stat created project, Stat runs the PeopleSoft project copy CLI twice: once for the Stat created project and once for the PS Project in the archive set. The CLI for the PS project only copies the project definition, but it updates the project version appropriately.

If the CLI Auto-Migration feature has not been activated, or if an error or warning occurs during the auto-migration, you must perform the migration manually by logging into the staging database and pushing the project into the target environment. If CLI-Open is configured for the staging environment, Stat opens App Designer in the staging database for you. For more information, see Manually Migrating PeopleSoft Projects .

IMPORTANT: Stat does not execute the CLI Open option for the staging database if the CLI Auto-Migration option has been activated for the target environment as well. If you or your system administrator activated the CLI Auto-Migration option for the target environment, Stat ignores the CLI Open function and automatically migrates the project from the staging database to the target environment. This minimizes the likelihood of developers inadvertently making changes to the staging database during a migration. It is therefore recommended that you use the CLI Auto-Migration feature for typical migration needs.