Chat now with support
Chat with Support

Stat 6.3 - System Administration Guide

Overview of Stat Administration Administrative Utilities Stat Security General Maintenance Tables
System Maintenance Service Domain Maintenance Department Maintenance Issue Tracking Maintenance Country Maintenance Customer Maintenance Object Type Maintenance PeopleSoft Environment Connection Maintenance Pre/Post Migration Steps Parameters Oracle Applications Configuration Oracle Applications Connection Maintenance Generic Application Connection Maintenance Schema Object Parameters Maintenance Data Object Maintenance PeopleSoft Search Configurations Stat Report Definition Maintenance Version Control Management Connection Maintenance
Service Domain-Specific Maintenance Configuring the Stat Central Agent Email Configuration Object Security Appendix: Sample Service Domain Configuration Appendix: User Class Rights Appendix: Creating a Staging Database Appendix: Database Tuning Appendix: Oracle Applications File Type Directory Appendix: Ports and Firewalls Appendix: REST Web Services API Appendix: SOAP-Based Web Services API Appendix: Troubleshooting Chart Appendix: stat.conf Configuration Appendix: Custom Report Files

Updating CSR Migration Paths with Additional Environments

You can add environments to existing migration paths that are already associated with CSRs. You then have the option of updating the migration path on selected CSRs to include the new environments.

* 
IMPORTANT: Be aware of the following:
•
Although you can add and remove environments from migration paths, you can only update the migration paths of existing CSRs after adding environments, not after removing them (see 2nd bullet below). Furthermore, you cannot update the migration paths of existing CSRs after replacing environments (i.e., removing one environment and adding another in its place).
•
Environments can be removed from the migration path maintenance table. However, removing an environment from a migration path will only be reflected on newly created CSRs. The environment will not be removed from existing or closed CSRs.
To add environments to CSR migration paths:
1
Open the migration path diagram you want to add an environment to.
2
Follow the instructions in the section Migration Path Diagram to add environments to the migration path.
3
Click Add new env. to CSR.
Stat displays a list of any open or closed CSRs currently associated with the migration path. You can select the CSRs you want to update. You can also opt to copy the objects from the Base or Development environment to the newly added environments on the migration path.
4
Select the Update option for each CSR you want to update.
5
Optionally, select the Update Objects List option if you want to copy the objects from either the Base or Development environment to the newly added environments. Then select Base or Dev.
6
Click OK.

Pre and Post Migration Steps

The Pre and Post Migration Steps Maintenance table defines the actions to be taken on certain types of objects in an archive set before or after it has been migrated. Pre and Post migration steps are either manual or automatic, i.e., they are triggered either manually by users or automatically during Stat migration.

The Pre and Post Migration Steps Maintenance table defines actions that should be taken before an archive set is migrated.

Pre and post migration steps security is controlled by the following user class rights:

•
Migration Steps - Add
•
Migration Steps - Edit

The Pre and Post Migration Steps Maintenance table is displayed in a standard maintenance window. To open this window, select Maintenance | Domain-Specific | Pre and Post Migration Steps.

Value
Description

Active

If selected, activates the value in Stat

Step Type

Defines whether step is Pre or Post

Migration Step
(Required Value)

The type of step. Options include Custom Command, Run DMS, Create Project Build Script, Compile Cobol, and Manual Step.

Auto

If this check box is selected, the step will be triggered automatically. Only Custom Command steps can be set to run automatically.

Description
(Required Value)

The name of the step

Object Class
(Key Value)

The class of object for which the step is defined. Options include data objects and file object for all three change management modules supported by Stat, as well as PeopleSoft Proprietary objects.

Object Type
(Key Value)

The object type the step is associated with (if any)

Run Order
(Required Value)

A number that determines the sort order for the step on the pre and post migration checklist. Steps with a lower number are executed first.

Target Environment

The target environment the step is associated with (if any)

Include Distributed

If this check box is selected, the step is also propagated to each distributed environment.

Run Once Per Env

If this check box is selected, the step will be deselected by default when it was already executed in the past.

User would still be able to add such step to the migration

Last Update
(Read Only)

The date and time that this record was last updated

Updated By
(Read Only)

The user that who updated this record

Step Types

Stat offers the following types of steps:

Custom Command

User can define custom command

 

Run DMS

Run PeopleSoft Data Mover script

PeopleSoft only

Manual Step

Step that is run outside of Stat

 

Create Project Build Script

Generate/execute PeopleTools Project Build script

PeopleSoft only

Compile Cobol

 

PeopleSoft only

Custom Command steps can be triggered automatically by Stat or manually. Other steps types are triggered manually.

Predefined Steps

Stat has three predefined PeopleSoft pre and post migration steps: Create Project Build Script, Compile COBOL, and Run DataMover Script. These steps are triggered manually by the migrator.

Create Project Build Script

When this step is triggered, Stat logs into the target PeopleSoft environment of the migration and creates the project build script for the project used during the migration. Stat uses the command line statement to launch PeopleSoft. It uses the PeopleSoft build settings from the Windows registry to generate the SQL script for create or alter.

Compile COBOL

When this step is triggered, Stat launches the PeopleSoft COBOL Compile program, either CBLBLD for NT or pscbl.mak for Unix. When executing this step, Stat uses the following file server variables:

•
The definition of the file server operating system (NT, Unix, or Mainframe).
•
The location of the COBOL Compiler for each file server that PeopleSoft COBOLs reside on. This location is defined in the File Servers tab of the Object Type Maintenance window.
•
The %PS_HOME% location for the COBOLs to be compiled. This value is taken from the Windows registry entry for PS_HOME. All the COBOL source programs residing in %PS_HOME%\src\cbl are compiled.
•
For NT servers, The location where the compile is to take place. By default, C:\temp\compile.
•
For Mainframe servers, the name and location of the JCL file used to upload cobols

Except for the definition of the operating system, all of these settings can be changed at the time of execution.

Run DataMover Script

When this step is triggered, Stat logs in to the PeopleSoft environment (by default, the target environment of the migration) using the user’s PS operator ID and password and runs the selected Data Mover script. By default, Stat uses the .dms file in the subdirectory “\script,” which is appended to the PeopleSoft Home Directory (PS_HOME) defined in the PeopleSoft Configuration Manager. All of these settings can be changed at the time of execution.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating