0

Evolution of PS_HOME

1. PTools 8.49 and earlier – A single PS_HOME

In PeopleTools 8.49.x and previous versions, there used to be a single home – PS_HOME, which contained the configuration files, source files, executables, customized code and everything else. It was just a single home for all the files delivered by PeopleSoft. With PeopleSoft 8.50.x version, we started seeing segregation or decoupling of this single home known as PS_HOME. While it seemed confusing a bit, but it made sense because files of similar nature were kept together and it allowed for robust security settings.

2. PTools 8.50 – Introduction of PS_CFG_HOME

Introduction of PS_CFG_HOME or Configuration Home was the first improvement in this direction and was introduced in PeopleTools 8.50 version. When you installed PeopleTools software, the installation program installed all required files for that server into PS_HOME. After creation of a domain, the configuration files associated with that domain stared residing in PS_CF_HOME i.e. primarily the domain configuration and log files were removed from PS_HOME, giving us an option to make PS_HOME read-only.

Let’s spend a minute more here to understand the difference:

Location	File Type	Description	File Examples
PS_HOME	Binary	Compiled, non-modifiable executables and libraries	psadmin.exe psappsrv.exe psodbc.dll
PS_CFG_HOME	ASCII	Text files associated with configuration and administration of a domain.	psappsrv.cfg psappsrv.cfx pstuxcfg appsrv_<date>.log

* You will find a few ASCII files in PS_HOME, but they should be considered as non-modifiable for all practical purposes. You can create multiple domains (which reside in PS_CFG_HOME) but all of them refer to the same PS_HOME.

Advantages of having separate PS_HOME and PS_CFG_HOME:

1. You install PS_HOME binaries a single time.
2. You get the ability to apply updates and upgrades to a single PS_HOME, which reduces the upgrade time.
3. You get the ability to add additional servers for additional domains, if need arises.
4. Different security can be applied to PS_HOME and PS_CFG_HOME. Basically you can completely lock down the PS_HOME till next patch or upgrade.

When you install PS_HOME, it installs what is known as the default PS_CFG_HOME. This default PS_CFG_HOME exisits in the “user” directory of the current user or the owner of the domain.

After you create a domain, the domain exists under $PS_CFG_HOME\appserv\<domain>.

When you launch PSADMIN, it will either create (if one doesn’t exist) PS_CFG_HOME or search for PS_CFG_HOME, based on the current environment settings. To start PSADMIN, the following conditions need to be fulfilled:

• PS_CFG_HOME must be a valid location. That is, the base directory must exist (UNIX), or the drive must exist (Windows).
• The PS_CFG_HOME must be writeable, and the user running PSADMIN must have write access to the PS_CFG_HOME location.

When working with decoupled PS_HOME and PS_CFG_HOME directory structures, keep these recommendations in mind:

• Use distinct PS_CFG_HOME locations for each PS_HOME. When a PS_CFG_HOME is created, PSADMIN brings content from the current PS_HOME into the PS_CFG_HOME, which effectively binds that PS_CFG_HOME to that PS_HOME. That is, all domains within a given PS_CFG_HOME should reference the same PS_HOME. Domains in the same PS_CFG_HOME that reference different PS_HOMEs can encounter unpredictable behavior, especially when applying updates to the system.
• Install as few PS_HOMEs as possible. Ideally, each PS_CFG_HOME requiring the same PeopleTools release level points to the same PS_HOME. This approach helps reduce the number of locations that require patches to be applied.
• After applying updates (patches) to the PS_HOME, recreate domains associated with that PS_HOME.
• A domain configured on one machine cannot be copied manually and run on another machine. Use the Replicate Config Home PSADMIN option to perform this task.
• The Windows service configuration file (PSWINSRV.CFG) will be invalid if it is shared between multiple PS_CFG_HOMEs on different network drives.
• As you maintain your system and upgrade domains, keep in mind that dormant domains will consume disk space. Make sure to keep track of where your retired domains reside and take action to remove them when no longer required. It is generally recommended to remove old log files and trace files for both efficiency and security purposes.

3. PeopleTools 8.52 – Introduction of PS_APP_HOME

The PS_APP_HOME environment variable decoupled application specific code from the PS_HOME and it refers to the location where you have installed the contents of your PeopleSoft application. Now you have a clear distinction between application code and PeopleTools code. Example of locations:

It is important to note that deciding whether to install your PeopleSoft application into a separate PS_APP_HOME should be considered while planning your installation. If you do not set the PS_APP_HOME environment variable explicitly, PeopleSoft runtime retrieves all runtime content from PS_HOME. That is, unless you set PS_APP_HOME to a value different than PS_HOME, the system assumes PS_APP_HOME=PS_HOME.

Installing your application into PS_HOME is still assumed to be the default approach, and, if you elect to stay with this model, there is no change to your existing PeopleSoft system management experience. However, sites that take advantage of the PS_APP_HOME option can expect a variety of benefits, including:

• PeopleTools patches and updates and application updates can be applied independently of each other.
• Increased flexibility and modularity in that a single PS_HOME can be associated with multiple PS_APP_HOME locations.
• Disk space savings, due to shared PS_HOME amongst multiple PS_APP_HOME locations.
• When troubleshooting it will be easier to isolate application and PeopleTools issues.

3. PeopleTools 8.53 – Introduction of PS_CUST_HOME

PeopleTools 8.53 extends the decoupling of PS_HOME approach to introduce PS_CUST_HOME (Customization Home). By using PS_CUST_HOME for any customer-specific code, a clear distinction is made between code delivered by PeopleTools and PeopleSoft applications and that produced by individual customers. This change is optional; customers may continue to use a traditional PS_HOME if desired.

Examples of customized files that might be stored in PS_CUST_HOME include:

• Data Mover scripts.
• DAT files.
• COBOL programs.
• SQR programs.
• Crystal Reports.
• Java class files.

With your custom files stored in the PS_CUST_HOME location, you can freely take PeopleTools or PeopleSoft application upgrades and maintenance updates, knowing that your customized files will not be affected.

With PS_CUST_HOME, all customizations can be consolidated into a single, isolated PS_CUST_HOME, and multiple runtime environments can utilize the resources within that PS_CUST_HOME. If separate environments require different customizations, they can share the same PS_HOME and PS_APP_HOME but point to separate PS_CUST_HOME locations.

An environment where PS_CUST_HOME is implemented may have the following environment variables set.

For details refer to the PeopleSoft PeopleTools 8.53 System and Server Administration Guide.