Chat now with support
Chat with Support

Stat 6.0 - User Guide

Introduction to Stat Connecting to Stat Change/Service Requests Stat Consoles Tasks and Time Entries Stat Projects Search Engines Reports and Graphs Personal Rules Object Tools and Wizards Change Management for PeopleSoft
Object Management (PeopleSoft) Object Archives (PeopleSoft) Object Migrations (PeopleSoft)
Change Management for Oracle Applications
Object Management (Oracle Applications) Patch Management Object Archives (Oracle Applications) Object Migrations (Oracle Applications)
Change Management for Generic Applications
Object Management (Generic Applications) Object Archives (Generic Applications) Object Migrations (Generic Applications)
Appendix: Troubleshooting Chart Appendix: Migration Options Appendix: User-Specific Parameters Appendix: Supported PeopleSoft Proprietary Objects Appendix: Stat Reports

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.

2
Select Tools | Copy Project to copy the project from the staging database to 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.

Regarding Pre and Post Migration Steps windows:

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.

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.

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.

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

1
In the Command with parameters field, enter the command you want Stat to run.
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.”
3
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.
5

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.

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.

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

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.

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

9

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.

2
Select Complete for each step that Stat performs successfully.
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.
4

You can go into the Development environment in PeopleSoft and begin making changes to the PeopleSoft proprietary objects.

The process is the same for migration of all types of archive sets.

Point-to-Point PeopleSoft Project Migrations

If you want to migrate a PeopleSoft project that contains a large number of objects, but you do not necessarily want to spend the time required to archive all these objects, you can use Stat simply as a migrating tool by performing a point-to-point migration.

During a point-to-point migration, Stat uses CLI functionality to open PeopleSoft and migrate the objects in the project directly from the source environment to the target. Stat does not stage the objects and does not archive them. This means that while a record of the migration is recorded in Stat for reporting purposes, you cannot use Stat to roll back the migration since none of the objects in the project were archived.

To execute a point-to-point migration, you must add the project you want to migrate to a CSR and the CLI Auto-Migration option must be activated for both the source and target PeopleSoft database. For more information on activating CLI functionality, see the section, Setting Up Your PeopleSoft Connections .

6
(Optional) In the Description field, enter a unique description of the migration.
8
Click Migrate.

Migrating Non-App Designer PeopleSoft Proprietary Objects

When Stat migrates PeopleSoft proprietary objects, it first moves copies of the archived objects into a staging database. Stat then creates a PeopleSoft project (called an Application Designer project), which contains references to the objects you just staged. However, there are PeopleSoft proprietary objects that cannot be included in an Application Designer project. For some of these objects, Stat provides an alternative form of migration support. These objects include:

 

You archive non-Application Designer objects the same way you do other PeopleSoft proprietary objects. When you migrate them, however, Stat executes the following steps after the archived objects are moved to the staging database:

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating