Stat 6.1 - User Guide

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 accidently 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.

Also, Stat does displays an error 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). Instead, this information is displayed in the Migration History window. For more information, see Documenting Migrations (Generic Applications) .

Running a Migration (Generic Applications)

To run a migration:

Open the Change Management/Version Control window and do one of the following:

•

In the Migration Path tab, click and hold your cursor over the source environment for the archive set and drag and drop it in the target environment.

•

In the Object Management tab, click Archive Sets to display the Archive Sets table. Then drag and drop the archive set you want from the table to the target environment's tree node.


	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 (Generic Applications) .

Stat opens the Migration window.

(Optional) If you want the Stat Central Agent to process the migration job at some later time, enter the date and time in the Migration Date field.

The field defaults to the current date and time. You can schedule the migration up to 90 days in the future.

(Optional) In the Description field, enter a unique description of the migration.

The field defaults to CSR ID+Archive ID.

(Optional) Select the Stop on Error option if you want the Stat Central Agent to terminate the migration at the first error it encounters.

System administrators may set this option to be selected or de-selected by default.

(Optional) De-select the E-mail Notification option if a business rule or personal rule triggered by a migration event has been defined for the service domain and you do not want Stat to send email notifications that may be triggered by the migration.

This option is selected by default and is displayed only if one or more Migration Notification business or personal rules have been defined for the service domain. Fore more information, see Defining Personal Rules .

Select the archive set you want to migrate.

The window displays a list of archive sets that you can migrate from the selected environment. If you initiated the migration from the Object Management tab, the list displays only the archive set that you dragged and dropped onto the target environment.

By default, all the objects in the archive set are selected for the migration. However, with the appropriate security rights, you can exclude either all the file objects or all the database objects from the migration. You can also exclude individual objects.

(Optional) De-select the class of objects (file objects or database objects) you do not want to migrate.

(Optional) In the Migrate column, de-select the individual objects you do not want to migrate.

If you are migrating to a distribution environment, the window displays the list of active target environments. By default, each environment in the distribution list is selected as a target. However, with the appropriate security rights, you can exclude certain environments from the migration.

(Optional) If migrating to a distribution environment, de-select any environment in the list of active target environments you want to exclude from the migration.

If the archive set contains file objects and the target environment is Development, select one of the following options in the Migrate file to field:

•

Development Env – Select if you want to place the file objects in the source file locations of the Development environment

•

Working – Select if you want to place the file objects in the developers’ working directories. Only the file objects assigned to each developer get copied into their working directories.

•

Dev & Working – Select if you want to place the file objects in both the source file locations and the working directories. If the archive set does not contain any file objects or the target environment is not Development, this option is dithered with a value of “NA.”

Click Migrate.

At this point, Stat prompts you to perform the pre-migration steps (if any) that have been defined for the target environment or for the objects or object types in the archive set.

Complete any required pre-migration steps.

For more information, see Pre and Post Migration Steps .

After completing the pre-migration steps, Stat opens the CSR Migrations Console, which shows that the migration job has been submitted to the Stat Central Agent. The Agent either begins processing the migration immediately, or if you scheduled the migration, at the date and time you specified. For more information, see Migration Console .

If you are only migrating file objects, Stat copies the file objects into the target environment.

Pre and Post Migration Steps

Pre and post migration steps define certain activities you should perform before and after migrating an archive set. Migration steps are performed either manually by the user or automatically by Stat. The steps are meant to promote adherence to development standards and are not mandatory or enforced.

Pre and post migration steps can be associated with object types, object classes and with target environments. This means that when you initiate a migration with an archive set that includes an associated object type or class, or when you initiate a migration to an associated target environment in either a single or a mass migration, Stat opens the Pre Migration Steps window. This window displays a checklist of recommended actions that should be taken before the archive set is migrated.


	NOTE: System administrators can define pre migration steps that are not associated with either an object type or an environment. In this case, the step is triggered for all migrations.

As with Pre Migration steps, after you successfully migrate an archive set that contains an associated object type or class, or after you migrate to an associated target environment, Stat opens the Post Migration Steps window.

Regarding Pre and Post Migration Steps windows:

•

If the target environment is also a distribution environment, the distributed environments are listed in italics

•

For mass migrations, the CSR id is also listed on the left side of the window

•

The windows can also be opened from the Environment Status window and from the search results window of the Migration History Wizard

Unlike the Pre Migration Steps window, the Post Migration Steps window is not opened automatically. Instead, post migration steps have a default status of Pending, which means that until the user changes the status of a post migration step to either Complete or N/A (Not Applicable), the migration will have a status of Wait for Post Step in the Migration Console. This is how Stat prompts users to complete post migration steps as intended. Once all the post migration steps have been marked as Complete or N/A, the status of the migration will change to Complete.

Running Automatic Migration Steps

Automatic steps consist of custom commands defined by your system administrator. For more information on automatic steps, see the book, Stat System Administration, Chapter 5, “Service Domain-Specific Maintenance.”

To execute an automatic step, click Run. Depending on the step, Stat may prompt you to specify additional parameters.

Custom commands are operating system commands executed by the client server that Stat is running on. When a custom command step is triggered, Stat opens the Custom Command Variables window. Here you can edit the command by adding or replacing parameters as needed, or you can run the command directly.

When defining a command, system administrators can include predefined parameters and user and server-based parameters that have been defined in Stat. This provides a convenient way to specify values commonly invoked by operating system commands, such as server names and download directories. In addition, parameters offer a way to secure sensitive information by encrypting values that you do not want visible to users, such as passwords.

Predefined parameters specify values used to login to a target environment during a migration (database name, user name and password), whereas user and server-based parameters generally invoke values specific to the users and file servers defined in Stat. Also, certain parameters may be defined so that their values are different depending on which user or server they are being applied to. For more information on pre and post migration step parameters, see the book, Stat System Administration, Chapter 4, “General Maintenance Tables”.

To edit a custom command migration step:

In the Command with parameters field, enter the command you want Stat to run.

If you want to include parameters in the definition of the command, click the location where you want to insert the parameter and then double-click the parameter you want to insert. When included in a command, parameters are enclosed in double % signs, for example, “%%GL_PWD%%”.

Certain users and servers may have parameters that have been defined exclusively for them, or the value of a particular parameter may be different depending on which user or server it is being applied to. When the Stat Command Editor is first opened, the parameters are listed as they have been defined for the local client server and the current user. If you want to include parameters defined for a different server, click in the Server field and select the server you want. Although you cannot select a different user in the User field, when a user executes the command during a post migration, they will have the option of inserting their own parameters or overriding default values.


	NOTE: System administrators can restrict user access to certain servers at the service domain level. The servers displayed in the Server field drop-down list may be limited if the server access of the current user has been restricted. For more information, see Stat System Administration, Chapter 3, “Stat Security.”

If the command you want to execute opens a window, specify if you want the window minimized, maximized, or normal size.

This value is saved and used at run time.

Click Interpret >>.

The Interpreted Command field displays how the command is interpreted by the client server. Null values and encrypted values are enclosed in angle brackets. Encrypted values are not displayed but replaced with asterisks.

(Optional) Verify that you defined the command properly by selecting the server you want to use to test the step in the Server field.


	NOTE: This is for testing purposes only. During execution of the step a user can select a different server.

Click OK.

Viewing Migration Step History

To view the history of any automatic step, select it and click History. This opens the Migration Step History window, which displays a record of each time Stat successfully executed the command. These records display the date and time the step was run, the user who ran it, and what parameters were used.

To view the log for the step, click Log. To print the history table, click Print. To export it to a file format, click Export.

To run pre and post migration steps:

In the Pre or Post Migration Steps windows, run each automatic step you want Stat to perform, specifying any additional parameters you want.

Select Complete for each step that Stat performs successfully.


	NOTE: Stat displays an error message if it is unable to execute an automatic step. Also, Stat does not notify you if after it completed the step successfully the external application encountered errors. For example, when running the Compile Command step, Stat only knows if the command was executed properly. It does not know if the compile was successful or not. In this case, you will need to check the compile yourself.

(Optional) Complete any manual steps, or perform them at a later time as required. Then select Complete for each step you perform.


	NOTE: Until a post migration step has been marked as either Complete or N/A (non-applicable or not applied), the migration will have a status of Wait for Post Step in the Migration Console. Once all the post migration steps have been marked as Complete or N/A, the status of migration will change to Complete.