Chat now with support
Chat with Support

Stat 6.1 - 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: Stat Web Services 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.

Post Migration Steps

The Post Migration Steps Maintenance table defines the actions to be taken on certain types of objects in an archive set after it has been migrated. Post migration steps are either manual or automatic, meaning they are performed either by users or by Stat.

Post migration steps security is controlled by the following user class rights:

•
Post Migration Steps - Add
•
Post Migration Steps - Edit

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

Value
Description

Active

If selected, activates the value in Stat

Post Migration Step
(Required Value)

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

Step Name
(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)

Target Env.

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

Run Per

If selected, specifies that the step should be run only once for a particular CSR, migration, or target environment. This option is used to prevent a step from being run multiple times when it should be run only once. The default option is Migration.

Order
(Required Value)

A number that determines per object type the sort order for the step on the post migration checklist. Steps with a lower number are displayed at the top of the list.

NOTE: Sort order is based on object type, meaning steps for two different object types can have the same sort number. Also, Stat uses increments of 10 when compiling the sort order. This means that if you assign a sort number to a step that is not an increment of ten, after you save Stat will resort the list correctly but will reassign each step a sort number based on an increment of 10.

Last Update
(Read Only)

The date and time that this record was last updated

Update By
(Read Only)

The user that who updated this record

Predefined Automatic Steps

Stat can execute three predefined, automatic post migration steps: Create Project Build Script, Compile COBOL, and Run DataMover Script.

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. This step is applicable for PeopleSoft versions 8 and higher only.

Compile COBOL

When this step is triggered, Stat automatically 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 (PeopleSoft Only)

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.

Defining a Custom Command

You can define automatic post migration steps in the form of custom commands. These are operating system commands executed by the client server Stat is running on. All drive mappings and file paths are relative to the client server.

To define a custom command:
1
In the Post Migration Step Maintenance window, click New and specify the object class and object type of the automatic step you want to create.
2
In the Automatic Post Migration Step field, select Run Custom Command.
3
Specify a name for the step in the Custom Step Name field.
4
Click Apply to save your work.
5
Click Define Command.
Stat opens the Pre/Post Migration Step Command Editor window.
When defining a command, you can include predefined parameters as well as 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 into an environment during a migration (database name, user name and password) or to invoke Stat web services (service domain and CSR ID). User and server-based parameters, on the other hand, generally invoke values associated with 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, see the section, Pre/Post Migration Steps Parameters .
* 
NOTE: In the case of Oracle-based environments, predefined parameters also include host name, service name, DB listener port, and TNS entry, and for Oracle Applications environments, APPL_SYS_USERNAME and APPL_SYS_PASSWORD.
The Stat Command Editor also supports special symbols representing different variables:
Symbol
Interpretation
Example

<<YY>>

The current year, 2-digit format

01

<<YYYY>>

The current year, 4-digit format

2001

<<MM>>

The current month, 2-digit format

01

<<DD>>>

The current day of month, 2-digit format

31

<<DDD>>

The current day of week

Monday

<<HH>>

The current hour, 2-digit format

13

<<NN>>

The current minutes, 2-digit format

45

<<SS>>

The current seconds, 2-digit format

23

<<ENV>>

The target environment of the migration

PROD

<<PROJ>>

The name of the PeopleSoft project used in the migration

ST001095

<<SDCD>>

The service domain that the CSR belongs to

HR

<<CSRID>>

The CSR ID number

6086

<<OBJTYPE>>

The object type the post migration step is defined for

Panel

For example, if you are defining a command that invokes the current date and time, you could enter the following special symbols:
<<YYYY>>-<<MM>>-<<DD>> <<HH>>:<<NN>>:<<SS>>
6
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 %% signs, for example, “%%GL_PWD%%.”
Certain users and file servers may have parameters that have been defined specifically 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.
7
If you are defining a custom run command for an object in an archive set, select one or more objects in the Objects field.
Stat includes a predefined TARGET_OBJECT_NAME parameter that you can use in custom run commands for objects.
* 
NOTE: If you do not select an object when using the TARGET_OBJECT_NAME predefined parameter, you will receive an error message.
8
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.
9
(Optional) If you have SSH installed and properly configured and would like to use it to execute the command on a remote sever, select the option, Execute command via SSH.
* 
NOTE: When using SSH, be aware of the following:
•
Semi-colons between commands will designate new SSH connection sessions.
•
A double ampersand (&&) between commands link the commands together in one SSH session.
•
Use single forward slashes and double back slashes when defining commands (single back slashes are stripped by SSH, causing the step to fail).
If the command is still running when the connection times out, no log is attached to Stat. However, you can adjust the 5 second default SSH connection timeout setting. A longer connection timeout setting allows the SSH session to stay connected the entire time the command is being processed, in which case the SSH session log will be attached to Stat.
10
(Optional) In the SSH time-out in seconds field, specify a longer connection timeout amount.
11
(Optional) Click Interpret Command.
The Interpreted Command field displays how the command is interpreted by the client/server. Be aware, however, that certain variables can only be resolved when the user opens the Command Editor window during a migration. When the Command Editor window is opened by a system administrator through the maintenance window, the following restrictions apply:
•
Encrypted values are passed but are displayed by asterisks (this is also the case during migrations)
•
Special symbol variables (the variables listed above in double angle brackets) are not resolved and remain in double angle brackets
•
Variables that are CSR, archive set, or target/source environment-specific are not resolved
12
(Optional) Click Run Command.
This executes the command as it is currently defined in the maintenance window.
* 
NOTE: When the Command Editor window is opened by a system administrator through the maintenance window, the Run Command button is limited the same way as the Interpret Command button in terms of resolving certain types of variables. See the list of restrictions in the preceding step.
13
(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.
14
Click OK.
* 
NOTE: All Post Migration Step commands are processed by the Stat Central Agent. The Stat Central Agent must be up and running before the commands can be executed.
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating