Stat 6.1 - User Guide

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 (PeopleSoft) .

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 PeopleSoft objects from the migration. You can also exclude individual objects.

(Optional) De-select the class of objects (file objects or PeopleSoft 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, in the Migrate files to field select one of the following options:

•

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.


	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.

At this point, if you are only migrating file objects, you are ready to start the migration and can skip to Step 14. The remaining fields are dithered if there are no PeopleSoft proprietary objects in the selected archive set.

Select a staging database.

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.

(Optional) If CLI Auto Migrate has been enabled for the target environment, deselect the Auto Migration if for some reason you do not want Stat to auto-migrate the PeopleSoft proprietary objects.

It is recommended that you leave the Auto Migration option selected. If auto-migration is turned off, you need to manually migrate the PeopleSoft objects to the target environment. This also prevents Stat from executing the DataMover script to migrate non-App Designer objects.

Whenever you migrate an archive set that contains PeopleSoft proprietary objects, Stat creates a unique PeopleSoft project in the staging database. At this point, you need to specify a name for the project and, if you have migrated the archive set more than once, whether you want Stat to restage the objects in the project.

Select one of the following options to name the Stat-created PeopleSoft project:

•

Stat defined project - Select this option if you want Stat to assign a name to the project. Stat-defined project names always use the naming convention, “ST######.”

•

User defined project - Select this option if you want to assign a name to the PeopleSoft project. Then in the Project Name field enter the name you want.

•

Project in Archive Set - Select this option if you added a project definition to the archive set and want to re-use the project name. This option is only available if the archive set and the project definition included in the archive set reference all the same App Designer objects. This also applies to subobjects, meaning the option is not available if the parent objects have been removed either from the archive set or the project definition included in the archive set. The project definition included in the archive set can reference subobjects so long as the subobjects' parents are in the project definition and the archive set. For more information on subobjects, see Associating Related PeopleSoft Proprietary Objects .


	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.

•

Reuse project - Select this option if you are migrating an archive set that was previously migrated using the same staging database, and you have not modified the archive set after its original migration. If you select this option, by default Stat restages the project in the staging database. However, you can de-select the Restage objects option if you do not want to wait for the objects to be restaged and you are sure they were staged successfully the last time.


	IMPORTANT: In PeopleSoft 8.x, 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.

(Optional) Click the Audit Flags button to change the default audit flags and DDL settings for the project.

This opens the Upgrade Options window where you can specify whether these properties will be copied into the target environment during the migration or whether the settings as defined in the target environment will be retained. For PeopleSoft 8.40 and higher, additional settings include portal structure permission lists, display size page property, and the database field format.


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

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. If you are migrating PeopleSoft objects, what happens next depends on whether the CLI Auto-Migration feature has been activated for the target environment. For more information, see the section Auto-Migrating PeopleSoft Projects .

If you are not auto-migrating, you need to open PeopleSoft and manually push the project to the target environment. For more information, see the section Manually Migrating PeopleSoft Projects .

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. This also applies to mass migrations.


	CAUTION: Stat auto-migrates objects to PeopleSoft environments version 7.5 and lower by executing a series of keystroke commands. For this reason, do not press any additional keys or open other applications during the auto-migration process since this could cause it to fail. This also applies to editing PeopleSoft proprietary objects.

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.

Manually Migrating PeopleSoft Projects

If the CLI Auto-Migration feature has not been activated (or you de-selected the Auto Migration check box), 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. You need to review the project and push it to the target environment manually.

•

If CLI-Open is not configured for the staging environment, you will need to open App Designer in staging on your own, review the project and push the project to the target environment manually.

To migrate a PeopleSoft project manually:

With the project Stat just created open in the staging database, verify that you included all the objects in the archive set that you wanted to migrate.

Select Tools | Copy Project to copy the project from the staging database to the target environment.

In the Migration Details window in Stat, select the migration and in the Migration Status field select Complete.

Stat verifies that the PeopleSoft project was successfully migrated. If any errors are encountered, the migration status is changed to Complete with Errors.


	NOTE: If you decide not to migrate the project for any reason, set the migration status to Cancel.

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.

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 predefined commands executed by Stat. These include running DataMover scripts and any custom commands defined by your system administrator. For post migration steps, two additional automatic steps are compiling COBOL files and creating project build scripts.

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.

Running Data Mover Scripts

When this step is triggered, Stat uses your PS operator ID and password to log in to the PeopleSoft environment (by default, the target environment of the migration) and runs the selected .dms file. Before executing the step, however, Stat displays the DataMover Variables dialog box. Here you can specify a different environment, which .dms file you want to run, and the location of the script files. For a default location, Stat appends the subdirectory “\script” to the PeopleSoft Home Directory (PS_HOME) defined in the PeopleSoft Configuration Manager.

The default script location is based on the registry entry for the version of PeopleSoft that you were last working in. If you are working with multiple versions of PeopleSoft, for example, 8.50 and 8.53, the default location is the 'current' entry in the registry. So, if you are migrating across PS 8.53 environments, but the current entry in the registry is for 8.50, then the entry for 8.50 is the default script location.

After specifying the variables you want, click Run to execute the step. You can run this step for each .dms file included in the migration, or you can run this step for the same file but in a different environment or script location.

Running Custom Command Migration Steps

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 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 when performing a pre or post migration step, 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.

Creating Project Build Scripts

The Create Project Build Script step is a post migration step applicable for PeopleSoft versions 8 and higher only. When this step is triggered, Stat uses your PeopleSoft operator ID and password to log into the PeopleSoft environment that is the target of the migration and creates the build script for the project that was used during the migration. Stat uses the PeopleSoft command line statement to accomplish this and the build settings from the Windows registry to generate the SQL script for Create or Alter. The build script is placed in the location specified for build settings in your PeopleSoft configuration.

Compiling Cobol Files - Local and Unix File Servers

When this post migration step is triggered, Stat automatically launches the PeopleSoft COBOL Compile program, either CBLBLD for NT or pscbl.mak for Unix. Your system administrator defines the default server and variables required to run the compiler. For Unix, these variables include the PeopleSoft home directory and the Cobol Compile directory. For Windows servers, these variables also include the drive and directory where the compile is to take place. If you want to specify a different server and variables, you can do so in the Cobol Compile Variables dialog box, which Stat opens when you click Run.

After specifying the variables you want, click Preview to see how the object will be compiled. If satisfied with the results, click Run to execute the step.

Compiling Cobol Files - Mainframe

Stat executes a Cobol Compile post migration step on a mainframe server as follows:

•

Stat logs in to the Mainframe using the Host id, user name and password defined on the File Server Maintenance table.

•

Stat changes the directory based on the values in the Directory and Cobol Compiler Location: Drive and Root Directory fields of the File Server Maintenance table.

•

If the Directory field has a value, it is displayed in the PS Home field on the Post Migration step window. This field cannot be modified on the Post Migration step window.

•

The Cobol Compiler Location:Drive and Root Directory value is displayed in the Cobol Compiler field on the Post Migration step window. This field can be modified when the step is run.

•

Stat parses the JCL file listed on the File Server Maintenance table and displays it in the preview window


	TIP: Before running the step, you can browse and select a different JCL file if there is more than one that could be used.

When running the step, Stat executes the login sequence as follows:

open 10.4.23.188 (Host field from File Server Maintenance)

USER (User field from File Server Maintenance)

PASSWORD (Password field from File Server Maintenance)

cd QA.STATSOFF.PARMLIB (Cobol Compiler field from File Server Maintenance)

quote

site Filetype=jes

Put JCL (puts whatever is in the preview portion of the Post Migration step) window

disconnect

quit

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 it completed the step successfully but 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.

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


	IMPORTANT: 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.