Friday, May 26, 2017
Interview with PeopleSoft Administrator Podcast: Cost-Based Optimizer Statistics in PeopleSoft
I recently recorded another interview with Dan Iverson and Kyle Benson for the PeopleSoft Administrator Podcast, this time about management of Cost-Based Optimizer Statistics in PeopleSoft systems.
Sunday, February 26, 2017
Running Unix Shell Scripts from the PeopleSoft Process Scheduler
It is nearly 10 years since I first wrote about how to call Unix shell scripts from the Process Scheduler. Although very little has changed, I have had a number of questions recently, so I thought it was time I checked the script and updated the posting. I have used PeopleTools 8.54 in the preparation of this note.
The Process Scheduler is essentially just a mechanism for initiating processes on another server. Mostly those are other PeopleSoft delivered executables. The exception is the Application Engine Tuxedo Server process (PSAESRV) where the Process Scheduler submits a service request message that is picked up by one of the server processes that are already running.
NB: although the PSAESRV server is configured by default in the Process Scheduler domain, Oracle recommends that you should only use this when you have lots of very short-lived (runtime less than 30 seconds) application engine processes. Typically, this only occurs in CRM.
(Update 2.7.2019) Dan Iverson of psadmin.io has also converted the psft.sh script to run on Windows in Powershell - see Process Scheduler and Powershell (https://psadmin.io/2019/07/02/process-scheduler-and-powershell/). The code is available on github in the ps-poweshell repository.
Process Type Definition
First you need to create a new process type. I chose to call it ‘Shell Script’. It runs a named shell wrapper script, psft.sh. The wrapper script calls the script that is to be executed. Note that the command line in the process type definition includes the fully qualified path.
Wrapper Script
This is the wrapper script, psft.sh, that will be called by the process scheduler.#!/bin/ksh
# (c) David Kurtz 2007
# Script: psft.sh
#
# Syntax: psft.sh DBNAME ACCESSID ACCESSPSWD PRCSINSTANCE command
# where
# DBNAME is the name of the PeopleSoft datbase with a corresponding TNS entry
# ACCESSID is the schema containing the PeopleSoft database
# ACCESSPSWD is the password to ACCESSID
# PRCSINSTANCE is the process instance number supplied by PeopleSoft
#
# Purpose: To start Standard UNIX Shell Script from Process Scheduler, and interface with the PeopleSoft Process Scheduler
# 07.09.2007 Initial Version
# 23.02.2017 Remove unnecessary logfiles section
#set -x
if [ $# -lt 4 ]; then
echo "Usage $0: <DBNAME> <ACCESSID> <ACCESSPSWD> <PRCSINSTANCE> <command>"
exit 1
fi
CONNECT=$2/$3@$11
PRCSINSTANCE=$4
shift 4
#
# Function to set status of API aware process instance
#
function prcsapi2
{
if [ $# -lt 2 ]; then
echo "Parameter Error in function $0"
exit 1
fi
TIMESTAMPCOL=${1}
STATUS=${2}
if [ ${PRCSINSTANCE} -gt 0 ];then
echo "Setting process request ${PRCSINSTANCE} to status ${STATUS}"
sqlplus -S /nolog <<!
set termout off echo off feedback off verify off
connect ${CONNECT}
UPDATE psprcsque
SET runstatus = ${STATUS}
, sessionidnum = $$3
, lastupddttm = SYSTIMESTAMP
WHERE prcsinstance = ${PRCSINSTANCE}
;
UPDATE psprcsrqst
SET runstatus = ${STATUS}
, prcsrtncd = ${PRCSRTNCD}
, continuejob = DECODE(${STATUS},2,1,7,1,9,1,0)4
, ${TIMESTAMPCOL} = SYSTIMESTAMP
, lastupddttm = SYSTIMESTAMP
WHERE prcsinstance = ${PRCSINSTANCE}
;
COMMIT;
exit
!
RET=$?
if [ ! $RET ];then
echo "SQL*Plus Error Return Code: $?"
fi
fi
}
#
# Main Execution Starts Here
#
echo $0:$*
date
uname -a
echo "Current Directory: `pwd`"
echo "Process log files in: ${PSPRCSLOGDIR}"
PRCSRTNCD=0
prcsapi begindttm 75
#set
#Run the command
$*
PRCSRTNCD=$?6
if [ ${PRCSRTNCD} -ne 0 ]; then
prcsapi enddttm 3 # failure
else
prcsapi enddttm 9 # success
fi
date- The Oracle user ID, password and TNS name for the PeopleSoft database are supplied in the first three parameters to the wrapper script. The PeopleSoft Process Instance number is the 4th command line parameter. These parameters are then removed with the shift command leaving any other parameters that have been specified.
- Function prcsapi sets the status on the process request row and updates the appropriate timestamp columns in the Process Scheduler tables.
- PSPRCSQUE.SESSIONIDNUM holds the operating system process ID of the shell executing the wrapper script.
- When the process completes and an end of process status is set (either 9 for success, 3 for failure or 2 for delete) CONTINUEJOB is set to 1, otherwise it is set to 0.
- When the wrapper scripts start it sets the process status on the process request record to 7 indicate that it is processing. This can be seen in the Process Monitor.
- The return code of the executed script is captured. Later it will be recorded on
PSPRCSRQST.PRCSRTNCD. A non-zero return code indicates an error and the process status will be set to error.
Process Definition
Now I can create a Process Definition that will use the process type twrapper script to execute another command or script.The first four parameters passed to the wrapper script are the name of the database, the access ID and password, and the process instance. A string of further parameters will be appended in the individual Process Definition that is the specific command and parameters to be executed.
It is important that this new process type is defined as being API aware. That means the process interacts with the Process Scheduler by updating the process status. You can see how the interaction should be done by looking at procedure Update-Process-Status in the delivered SQR library prcsapi.sqc. Otherwise, the Process Scheduler cannot determine their status. Consequently, all API-unaware processes have a run status of Success to indicate that they were started successfully.
I have written a silly test script called i that I want to be executed by the Process Scheduler. It just prints out the command line parameters as banner text to both standard output and a file called mybanner.log. This script will be called by psft.sh.
The Process Scheduler creates a working directory for each process request. It sets the variable $PSPRCSLOGDIR to the fully qualified location of this directory. Note that mybanner.sh changes the current directory to the location of this variable so that it writes mybanner.log there, and thus it is picked up by the distribution agent and made available via the report repository. You may wish to do this in your scripts.
Current working directory can be specified at Process Type or Process definition. However, during my testing, I found that these settings had no effect. The working directory of the script did not change, and the value was not found in any environmental variable.
#!/bin/ksh
#A silly script to test psft.sh
#(c) David Kurtz 2017
#banner function from http://stackoverflow.com/questions/652517/whats-the-deal-with-the-banner-command
if [ "$PSPRCSLOGDIR" ] ; then
cd $PSPRCSLOGDIR
fi
(
while [ $# -gt 0 ]
do
/opt/oracle/psft/ptdb/custhome/banner $1
shift
done
) | tee mybanner.log
exit $?
You can't quite see it in the screen shot, but the parameter list includes the process instance number:
/opt/oracle/psft/ptdb/custhome/mybanner.sh "Hello World" %%INSTANCE%%
Process Scheduler System Settings
During my testing, I found that it was necessary to specify output type settings for process type Other in the Process Scheduler System Settings; otherwise the output files were not posted to the report repository.
The newly defined Process can be run just as any other process is usually run. Any output from the script on the standard output channel is captured by the Process Scheduler and written to a log file that can then be viewed from the View Log/Trace facility within Process Monitor.
mybanner.log
H H ll ll
H H l l
H H eeee l l oooo
HHHHHHH e e l l o o
H H eeeeee l l o o
H H e l l o o
H H eeee lll lll oooo
W W ll d
W W l d
W W oooo rr rr l d
W W o o rr r l ddddd
W W W o o r l d d
W W W W o o r l d d
W W oooo rr lll dddd d
33333 99999 99999 5555555 00000
3 3 9 9 9 9 5 0 00
3 9 9 9 9 5 0 0 0
3333 999999 999999 55555 0 0 0
3 9 9 5 0 0 0
3 3 9 9 5 5 00 0
33333 99999 99999 55555 00000
Note that the current directory is reported as being the location of the Process Scheduler Tuxedo domain.
/opt/oracle/psft/ptdb/custhome/psft.sh:/opt/oracle/psft/ptdb/custhome/mybanner.sh Hello World 39950
Tue Sep 1 21:59:46 UTC 2015
Linux hcm.london.go-faster.co.uk 2.6.39-400.215.10.el5uek #1 SMP Tue Sep 9 22:51:46 PDT 2014 x86_64 x86_64 x86_64 GNU/Linux
Current Directory: /home/psadm2/psft/pt/8.54/appserv/prcs/PRCSDOM
Process log files in: /home/psadm2/psft/pt/8.54/appserv/prcs/PRCSDOM/log_output/OTH_DMKTEST_39950
Setting process request 39950 to status 7
H H ll ll
H H l l
H H eeee l l oooo
HHHHHHH e e l l o o
H H eeeeee l l o o
H H e l l o o
H H eeee lll lll oooo
W W ll d
W W l d
W W oooo rr rr l d
W W o o rr r l ddddd
W W W o o r l d d
W W W W o o r l d d
W W oooo rr lll dddd d
33333 99999 99999 5555555 00000
3 3 9 9 9 9 5 0 00
3 9 9 9 9 5 0 0 0
3333 999999 999999 55555 0 0 0
3 9 9 5 0 0 0
3 3 9 9 5 5 00 0
33333 99999 99999 55555 00000
Setting process request 39950 to status 9
Tue Sep 1 21:59:46 UTC 2015 Tuesday, January 17, 2017
Removing Redundant Indexes in PeopleSoft
This is the second of a two-part article that discusses how to identify and remove redundant indexes from a PeopleSoft system.
This article describes a script on my website (psredundantant.sql) that uses a similar query to that described in the previous article to identify redundant indexes from the metadata in the PeopleTools tables. It uses an anonymous block of PL/SQL so nothing is installed in the database. For each redundant index identified it:
Index A was marked inactive on all platforms because the superset index _ is active on all platforms.
PeopleSoft delivers some indexes for some platforms only. For example, PSETREENODE is only active on Informix. Therefore the script only deactivates the Informix platform flag on PSCTREENODE, and the platform flag changes to 'Some'. The index is still added to the project, but no attempt is made to create extended statistics or to make it invisible, and the index continues to be built on Oracle.
The comment applied to index C indicates that only the Informix flag was changed.
The final step, when you are satisfied that making the indexes invisible has no unacceptable consequences, is to drop the redundant indexes using the script generated by Application Designer
This article describes a script on my website (psredundantant.sql) that uses a similar query to that described in the previous article to identify redundant indexes from the metadata in the PeopleTools tables. It uses an anonymous block of PL/SQL so nothing is installed in the database. For each redundant index identified it:
- Adds the record and redundant index into an Application Designer project called REDUNDANT INDEXES. The record must also be added, otherwise Application will not generate a DDL script to remove the index.
- Unsets the platform flag on the redundant index if the superset index is active on the same platform. Thus Application Designer will generate a script to drop redundant indexes when the project is built. The redundant index definition remains in the record definition in case there is a need to revert the change.
- If the superset index is active on Oracle
- Creates and collects extended optimizer statistics on the combination of columns in the redundant index. If error ORA-00054 occurs, the exception will be ignored and the script will continue.
- Makes the index invisible. Note that indexes are not dropped. That can be done later by building an alter script for the project. It would be normal to test the consequences of making the indexes invisible for a while, and drop them later.
Sample Output
Project REDUNDANT INDEXES already exists
…
Record PSPROJECTITEM, Redundant Index C already in project
Creating Extended Statistics on PSPROJECTITEM for OBJECTVALUE4,OBJECTTYPE
Making index PSCPSPROJECTITEM invisible
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired
…
Record PSTREENODE, Redundant Index C already in project
…
Record TL_RPTD_TIME, Redundant Index C added to project
Making index PSCTL_RPTD_TIME invisible
Record TL_TA_BATCH, Redundant Index _ added to project
Making index PS_TL_TA_BATCH invisible
Making index PS_TL_TA_BATCH1 invisible
…
Making index PS_TL_TA_BATCH48 invisible
…
Record WRK_XREF_CALC, Redundant Index A already in project
Creating Extended Statistics on PS_WRK_XREF_CALC for PROCESS_INSTANCE,SEQ_NBR
Creating Extended Statistics on PS_WRK_XREF_CALC1 for PROCESS_INSTANCE,SEQ_NBR
…
Creating Extended Statistics on PS_WRK_XREF_CALC6 for PROCESS_INSTANCE,SEQ_NBR
Making index PSAWRK_XREF_CALC invisible
Making index PSAWRK_XREF_CALC1 invisible
…
Making index PSAWRK_XREF_CALC6 invisible
- The script commits any changes it makes. There is also a rollback command at the top to prevent it accidentally committing something else.
- Having run it once, should you immediately run the script again, nothing will be found because any redundant indexes have been marked as disabled on Oracle
- Should you want to revert changes, mark all indexes in the REDUNDANT INDEXES project as active on Oracle.
UPDATE psindexdefn
SET platform_ora = 1
, activeflag = 1
WHERE (recname, indexid) IN (
SELECT objectvalue1, objectvalue2
FROM psprojectitem
WHERE objecttype = 1
AND projectname = 'REDUNDANT INDEXES')
AND platform_ora = 0;
COMMIT;
Index A was marked inactive on all platforms because the superset index _ is active on all platforms.
PeopleSoft delivers some indexes for some platforms only. For example, PSETREENODE is only active on Informix. Therefore the script only deactivates the Informix platform flag on PSCTREENODE, and the platform flag changes to 'Some'. The index is still added to the project, but no attempt is made to create extended statistics or to make it invisible, and the index continues to be built on Oracle.
The comment applied to index C indicates that only the Informix flag was changed.
The final step, when you are satisfied that making the indexes invisible has no unacceptable consequences, is to drop the redundant indexes using the script generated by Application Designer
…
DROP INDEX PSCPSPROJECTITEM
/
DROP INDEX PSEPSPROJECTITEM
/
…
DROP INDEX PSAWRK_XREF_CALC
/
DROP INDEX PSAWRK_XREF_CALC1
/
…
DROP INDEX PSAWRK_XREF_CALC6
/
Thursday, January 12, 2017
Identifying Redundant Indexes in PeopleSoft
This is the first of a two-part series that discusses how to identify and remove redundant indexes from a PeopleSoft system.
I recently wrote a series of articles on my Oracle blog about identifying redundant indexes on an Oracle database. The same approach can be taken with PeopleSoft, but using the metadata in the PeopleTools tables rather than the database catalogue.
(This means you could take a similar approach for PeopleSoft on databases other than Oracle, but I can't say anything about the behaviour of other optimizers)
The following query returns a report of superset and redundant subset indexes in a PeopleSoft system. It can be downloaded as a script from my website (psredundant.sql).
The generic Oracle version of this script will identify subset indexes that are unique as redundant because the primary key and unique constraints can be altered to use the superset index. However, this query does not make subset unique indexes as redundant because PeopleSoft does not explicitly create unique constraints, only unique indexes. If I disabled a unique index, I would not be able to maintain the unique constraint via Application Designer.
Subquery IC returns a list of columns for each index. Subqueries UNI, AS2 and USI retrieve columns for unique/duplicate key, alternate search and user defined indexes respectively. The absolute value of key position is not important for this exercise, it is merely used to sort the column list in the listagg() function in subquery I.
I recently wrote a series of articles on my Oracle blog about identifying redundant indexes on an Oracle database. The same approach can be taken with PeopleSoft, but using the metadata in the PeopleTools tables rather than the database catalogue.
(This means you could take a similar approach for PeopleSoft on databases other than Oracle, but I can't say anything about the behaviour of other optimizers)
The following query returns a report of superset and redundant subset indexes in a PeopleSoft system. It can be downloaded as a script from my website (psredundant.sql).
The generic Oracle version of this script will identify subset indexes that are unique as redundant because the primary key and unique constraints can be altered to use the superset index. However, this query does not make subset unique indexes as redundant because PeopleSoft does not explicitly create unique constraints, only unique indexes. If I disabled a unique index, I would not be able to maintain the unique constraint via Application Designer.
Subquery IC returns a list of columns for each index. Subqueries UNI, AS2 and USI retrieve columns for unique/duplicate key, alternate search and user defined indexes respectively. The absolute value of key position is not important for this exercise, it is merely used to sort the column list in the listagg() function in subquery I.
REM psredundant.sql
set lines 160 pages 50 trimspool on
column recname format a15
column superset_index format a60
column redundant_index format a60
break on recname skip 1 on indexid skip 1
spool psredundant
WITH uni AS (/*unique indexes*/
SELECT /*+MATERIALIZE*/ f.recname, i.indexid
, MIN(i.uniqueflag) OVER (PARTITION BY f.recname) uniqueflag
, CASE WHEN MAX(CASE WHEN f.recname != f.recname_parent THEN 1 ELSE 0 END) OVER (PARTITION BY f.recname)=1
THEN f.fieldnum ELSE k.keyposn END keyposn
, k.fieldname
FROM psrecfielddb f
, psindexdefn i
, pskeydefn k
WHERE i.recname IN(f.recname,f.recname_parent)
AND i.recname = k.recname
AND k.fieldname = f.fieldname
AND i.indexid = '_' /*unique index*/
AND k.indexid = i.indexid
AND bitand(f.useedit,3) > 0 /*unique or dup key*/
), as0 AS (/*leading column on alternate search indexes*/
SELECT f0.recname, k0.indexid, i0.uniqueflag, 0 keyposn, f0.fieldname
FROM psrecfielddb f0
, psindexdefn i0
, pskeydefn k0
WHERE bitand(f0.useedit,16) = 16 /*alternate search key*/
AND k0.recname = f0.recname_parent
AND k0.fieldname = f0.fieldname
AND i0.recname = k0.recname
AND i0.indexid = k0.indexid
AND i0.indexid BETWEEN '0' AND '9' /*alternate search index*/
), as1 AS ( /*now add unique columns*/
SELECT as0.recname, as0.indexid, as0.uniqueflag, as0.keyposn, as0.fieldname
FROM as0
UNION ALL /*append unique key index columns*/
SELECT as0.recname, as0.indexid, as0.uniqueflag, uni.keyposn, uni.fieldname
FROM as0, uni
WHERE as0.recname = uni.recname
), as2 AS (
SELECT as1.recname, as1.indexid, as1.uniqueflag, NVL(k.keyposn,as1.keyposn), as1.fieldname
FROM as1
LEFT OUTER JOIN pskeydefn k /*to handle custom key order*/
ON k.recname = as1.recname
AND k.indexid = as1.indexid
AND k.fieldname = as1.fieldname
), usi AS (/*user indexes*/
SELECT i.recname, i.indexid, i.uniqueflag, k.keyposn, k.fieldname
FROM psindexdefn i
, pskeydefn k
WHERE k.recname = i.recname
AND k.indexid = i.indexid
AND k.indexid BETWEEN 'A' AND 'Z'
AND i.platform_ora = 1
), m AS (/*merge three kinds of index here*/
SELECT uni.recname, uni.indexid, uni.uniqueflag, uni.keyposn, uni.fieldname
FROM uni
UNION ALL
SELECT as1.recname, as1.indexid, as1.uniqueflag, as1.keyposn, as1.fieldname
FROM as1
UNION ALL
SELECT usi.recname, usi.indexid, usi.uniqueflag, usi.keyposn, usi.fieldname
FROM usi
), ic AS ( /*list of columns, restrict to tables*/
SELECT r.recname, m.indexid, m.uniqueflag, m.keyposn, m.fieldname
FROM m
, psrecdefn r
WHERE r.rectype IN(0,7)
And r.recname = m.recname
), i AS ( --construct column list
SELECT /*+ MATERIALIZE*/
ic.recname, ic.indexid, ic.uniqueflag
, count(*) num_columns
, listagg(ic.fieldname,',') within group (order by ic.keyposn) AS fieldlist
FROM ic
GROUP BY ic.recname, ic.indexid, ic.uniqueflag
)
SELECT r.recname
, i.indexid||' ('||i.fieldlist||')' superset_index
, r.indexid||' ('||r.fieldlist||')' redundant_index
FROM i
, i r
WHERE i.recname = r.recname
AND i.indexid != r.indexid
AND r.uniqueflag = 0 /*non-unique redundant*/
AND i.fieldlist LIKE r.fieldlist||',%'
AND i.num_columns > r.num_columns
order by r.recname, r.indexid
/
spool off
RECNAME SUPERSET_INDEX REDUNDANT_INDEX
--------------- ------------------------------------------------------------ -----------------------------------------------------------
…
HRS_APP_PROFILE C (HRS_AL_LOG_ID,HRS_PERSON_ID) B (HRS_AL_LOG_ID)
HRS_SJT_JO B (HRS_JOB_OPENING_ID,SCRTY_TYPE_CD) A (HRS_JOB_OPENING_ID)
HR_PROMOTE_XREF C (EMPLID,EMPL_RCD) A (EMPLID)
B (EMPLID,EMPL_RCD,ACTION_DT_SS,EFFSEQ) A (EMPLID)
B (EMPLID,EMPL_RCD,ACTION_DT_SS,EFFSEQ) C (EMPLID,EMPL_RCD)
HR_SSTEXT_EFFDT _ (OBJECTOWNERID,HR_SSTEXT_SUB_ID,TEXT_ID,EFFDT) A (OBJECTOWNERID,HR_SSTEXT_SUB_ID,TEXT_ID)
HR_TRANSFR_XREF C (EMPLID,EMPL_RCD) A (EMPLID)
B (EMPLID,EMPL_RCD,ACTION_DT_SS,EFFSEQ) A (EMPLID)
B (EMPLID,EMPL_RCD,ACTION_DT_SS,EFFSEQ) C (EMPLID,EMPL_RCD)
PA_ALIAS_USE 0 (ALIAS_TYPE,ALIAS_NAME) A (ALIAS_TYPE)
…
WRK_XREF_CALC _ (PROCESS_INSTANCE,SEQ_NBR,XREF_NUM) A (PROCESS_INSTANCE,SEQ_NBR)
Thursday, July 07, 2016
Setting Environment Variables in Application Server/Process Scheduler Tuxedo Domains
The topic of how to manage environment variables was mentioned recently on the PeopleSoft Administrator Podcast
Recently I have built a pair of PeopleSoft environments for a proof-of-concept and have faced into exactly this problem. I have two PS_APP_HOMEs (application homes) share the same PS_HOME (PeopleTools home). The environment variables need to be correct before I open psadmin to administer the application server and process scheduler domains.
On Unix, I would usually recommend running domains for different PS_APP_HOMEs in different Unix user accounts. Thus environmental variables can be set up in the .profile or .bashrc scripts. The processes then run as different Unix users which makes them easier to monitor. The Unix users should be in the same Unix group and have group permissions to the PS_HOME directory. This approach is not possible on Windows.
The alternative is to have a scripts or a menu that sets up those variables before you enter psadmin.
I noticed that there is a new menu in the domain configuration menu in psadmin which permits you to set environmental variables that are then built into the Tuxedo domain configuration. In fact this has always been possible by editing the psappsrv.ubx and psprcs.ubx files directly to cause variables to be created in the psappsrv.env and psprcs.env files, but now you just have to enter the variables through the menu in psadmin.
When we start psadmin we can see the relevant environmental parameters. PS_APP_HOME points to my HR installation.
Although, you can add additional variables in psappsrv.cfg, thus
You have always been able to do this in Tuxedo, but you would have had to edit the psappsrv.ubx file yourself, now the menu allows you to administer this.
There is no way to view the psappsrv.ubx and psappsrv.env files from within psadmin, only psappsrv.cfg can be opened. If you want to check your settings have reached the psappsrv.env file, you will need to leave psadmin and look in the files for yourself.
Recently I have built a pair of PeopleSoft environments for a proof-of-concept and have faced into exactly this problem. I have two PS_APP_HOMEs (application homes) share the same PS_HOME (PeopleTools home). The environment variables need to be correct before I open psadmin to administer the application server and process scheduler domains.
On Unix, I would usually recommend running domains for different PS_APP_HOMEs in different Unix user accounts. Thus environmental variables can be set up in the .profile or .bashrc scripts. The processes then run as different Unix users which makes them easier to monitor. The Unix users should be in the same Unix group and have group permissions to the PS_HOME directory. This approach is not possible on Windows.
The alternative is to have a scripts or a menu that sets up those variables before you enter psadmin.
I noticed that there is a new menu in the domain configuration menu in psadmin which permits you to set environmental variables that are then built into the Tuxedo domain configuration. In fact this has always been possible by editing the psappsrv.ubx and psprcs.ubx files directly to cause variables to be created in the psappsrv.env and psprcs.env files, but now you just have to enter the variables through the menu in psadmin.
When we start psadmin we can see the relevant environmental parameters. PS_APP_HOME points to my HR installation.
PSADMIN -- PeopleTools Release: 8.54.16
Copyright (c) 1996, 2014, Oracle. All rights reserved.
--------------------------------
PeopleSoft Server Administration
--------------------------------
PS_CFG_HOME /home/psadm1/psft/pt/8.54
PS_HOME /opt/oracle/psft/pt/tools
PS_APP_HOME /opt/oracle/psft/pt/hr91
PS_CUST_HOME /opt/oracle/psft/pt/hr91/pscust
1) Application Server
…
----------------------------------------------
Quick-configure menu -- domain: RASC3K
----------------------------------------------
Features Settings
========== ==========
1) Pub/Sub Servers : Yes 17) DBNAME :[XXXXXX]
…
Actions
=========
14) Load config as shown
15) Custom configuration
16) Edit environment settings
h) Help for this menu
q) Return to previous menu
HINT: Enter 17 to edit DBNAME, then 14 to load
--------------------------------------
PeopleSoft Domain Environment Settings
--------------------------------------
Domain Name: RASC3K
TEMP :[{LOGDIR}{FS}tmp]
TMP :[{LOGDIR}{FS}tmp]
TM_BOOTTIMEOUT :[120]
TM_RESTARTSRVTIMEOUT :[120]
TM_BOOTPRESUMEDFAIL :[Y]
FLDTBLDIR32 :[{$TUXDIR}{FS}udataobj]
FIELDTBLS32 :[jrep.f32,tpadm]
ALOGPFX :[{LOGDIR}{FS}TUXACCESSLOG]
INFORMIXSERVER :[{$Startup\ServerName}]
COBPATH :[{$PS_APP_HOME}/cblbin:{$PS_HOME}/cblbin]
PATH :[{$PATH}:{$Domain Settings\Add to PATH}]
PS_APP_HOME :[/opt/oracle/psft/pt/fin91]
PS_CUST_HOME :[/opt/oracle/psft/pt/fin91/pscust]
INTERFACE_HOME :[/opt/oracle/psft/pt/fin91/pscust/interfaces]
1) Edit environment variable
2) Add environment variable
3) Remove environment variable
4) Comment / uncomment environment variable
5) Show resolved environment variables
6) Save
h) Help for this menu
q) Return to previous menu
Command to execute (1-6, h or q) :
# ----------------------------------------------------------------------
*PS_ENVFILE
TEMP={LOGDIR}{FS}tmp
TMP={LOGDIR}{FS}tmp
TM_BOOTTIMEOUT=120
TM_RESTARTSRVTIMEOUT=120
TM_BOOTPRESUMEDFAIL=Y
FLDTBLDIR32={$TUXDIR}{FS}udataobj
FIELDTBLS32=jrep.f32,tpadm
ALOGPFX={LOGDIR}{FS}TUXACCESSLOG
{WINDOWS}
COBPATH={$PS_HOME}\CBLBIN%PS_COBOLTYPE%
INFORMIXSERVER={$Startup\ServerName}
# Set IPC_EXIT_PROCESS=1 to use ExitProcess to terminate server process.
# Set IPC_TERMINATE_PROCESS=1 to use TerminateProcess to terminate server process.
# If both are set, TerminateProcess will be used to terminate server process.
#IPC_EXIT_PROCESS=1
IPC_TERMINATE_PROCESS=1
PATH={$PS_HOME}\verity\{VERITY_OS}\{VERITY_PLATFORM}\bin;{$PATH};{$Domain Settings\Add to PATH}
{WINDOWS}
{UNIX}
INFORMIXSERVER={$Startup\ServerName}
COBPATH={$PS_APP_HOME}/cblbin:{$PS_HOME}/cblbin
PATH={$PATH}:{$Domain Settings\Add to PATH}
{UNIX}
PS_APP_HOME=/opt/oracle/psft/pt/fin91
PS_CUST_HOME=/opt/oracle/psft/pt/fin91/pscust
INTERFACE_HOME=/opt/oracle/psft/pt/fin91/pscust/interfaces
TEMP=/home/psadm1/psft/pt/8.54/appserv/XXXXXX/LOGS/tmp
TMP=/home/psadm1/psft/pt/8.54/appserv/XXXXXX/LOGS/tmp
TM_BOOTTIMEOUT=120
TM_RESTARTSRVTIMEOUT=120
TM_BOOTPRESUMEDFAIL=Y
FLDTBLDIR32=/opt/oracle/psft/pt/bea/tuxedo/udataobj
FIELDTBLS32=jrep.f32,tpadm
ALOGPFX=/home/psadm1/psft/pt/8.54/appserv/XXXXXX/LOGS/TUXACCESSLOG
# Set IPC_EXIT_PROCESS=1 to use ExitProcess to terminate server process.
# Set IPC_TERMINATE_PROCESS=1 to use TerminateProcess to terminate server process.
# If both are set, TerminateProcess will be used to terminate server process.
#IPC_EXIT_PROCESS=1
IPC_TERMINATE_PROCESS=1
IPC_TERMINATE_PROCESS=1
INFORMIXSERVER=
COBPATH=/opt/oracle/psft/pt/fin91/cblbin:/opt/oracle/psft/pt/tools/cblbin
PATH=/opt/oracle/psft/pt/fin91/bin:/opt/oracle/psft/pt/fin91/bin/interfacedrivers:/opt/oracle/psft/pt/tools/jre/bin:/opt/oracle/psft/pt/tools/appserv:/opt/oracle/psft/pt/tools/setup:/opt/oracle/psft/pt/bea/tuxedo/bin:.:/opt/oracle/psft/pt/oracle-client/12.1.0.1/bin:/opt/oracle/psft/pt/oracle-client/12.1.0.1/OPatch:/opt/oracle/psft/pt/oracle-client/12.1.0.1/perl/bin:/opt/mf/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/opt/oracle/psft/pt/tools/bin:/opt/oracle/psft/pt/tools/bin/sqr/ORA/bin:/opt/oracle/psft/pt/tools/verity/linux/_ilnx21/bin:/home/psadm1/bin::.
PS_APP_HOME=/opt/oracle/psft/pt/fin91
PS_CUST_HOME=/opt/oracle/psft/pt/fin91/pscust
INTERFACE_HOME=/opt/oracle/psft/pt/fin91/pscust/interfaces
Warning
I found that I had to specify fully resolved paths for the variables I defined. I do try setting variables in terms of other variables,…
PS_APP_HOME :[/opt/oracle/psft/pt/fin91]
PS_CUST_HOME :[{$PS_APP_HOME}{FS}pscust]
INTERFACE_HOME :[{$PS_CUST_HOME}{FS}interfaces]
…
==============ERROR!================
Value for PS_CUST_HOME: {$PS_APP_HOME}{FS}pscust, is invalid. Your environment
may not work as expected.
==============ERROR!================
PS_APP_HOME=/opt/oracle/psft/pt/fin91
PS_CUST_HOME=/opt/oracle/psft/pt/fin91/pscust
INTERFACE_HOME={$PS_APP_HOME}{FS}pscust/interfaces
Configuration Settings in the .ubx –v- .cfg
My only reservation is that there is now environment specific configuration in the psappsrv.ubx file, rather than the psappsrv.cfg file. When I have done this in the past I would create additional variables in psappsrv.cfg that were referenced from the psappsrv.ubx file. Thus the psappsrv.ubx was consistent across environments, and all the configuration is in the main configuration file psappsrv.cfg.Although, you can add additional variables in psappsrv.cfg, thus
[Domain Settings]
;=========================================================================
; General settings for this Application Server.
;=========================================================================
…
Application Home=/opt/oracle/psft/pt/fin91
Custom Directory=pscust
Interface Directory=pscust/interfaces
…
PS_APP_HOME={$Domain Settings\Application Home}
PS_CUST_HOME={$Domain Settings\PS_APP_HOME}{FS}{$Domain Settings\Custom Directory}
INTERFACE_HOME={$Domain Settings\PS_APP_HOME}{FS}{$Domain Settings\Interface Directory}
==============ERROR!================
Value for PS_APP_HOME: {$Domain Settings\Application Home}, is invalid. Your
environment may not work as expected.
==============ERROR!================
==============ERROR!================
Value for PS_CUST_HOME: {$Domain Settings\Application Home}{FS}{$Domain
Settings\Custom Directory}, is invalid. Your environment may not work as
expected.
==============ERROR!================Conclusion
Using this technique, it does not matter how environment variables are set when you go into psadmin to start the application server, the correct setting is defined in the Tuxedo domain and overrides that.You have always been able to do this in Tuxedo, but you would have had to edit the psappsrv.ubx file yourself, now the menu allows you to administer this.
There is no way to view the psappsrv.ubx and psappsrv.env files from within psadmin, only psappsrv.cfg can be opened. If you want to check your settings have reached the psappsrv.env file, you will need to leave psadmin and look in the files for yourself.
Subscribe to:
Posts
(
Atom
)
@go-faster.co.uk on BlueSky
Posts
